CÓMO conseguir que un programador esté 100% interesado en escribir un EA basado en su IDEA - página 7
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
Cuando se contacta con un cliente, hay que educarlo hasta que se dé cuenta de lo que realmente quiere.
Lo que quiero decir es que cuando se contacta con un cliente, hay que educarlo hasta que entienda lo que realmente quiere.
¡¡¡Qué demonios "no rara vez"!!! El cliente casi siempre está en un estado:
Cliente: "El ordenador puede hacerlo todo, ¿verdad?"
Programador: "Con algunos supuestos, sí".
Cliente: "Entonces hazme un gran botón rojo para mañana, para que pueda pulsarlo y conseguir lo que quiero..."
Programador : "¿Qué quieres?"
Zapper : "Todavía no lo sé, pero veremos qué podemos hacer"
Programador : "¿Cuál es el objetivo principal? Tengo que programar algo para mañana".
Cliente: "¿Cuál es el problema?"
Bueno, el último truco acaba de matarme (el diálogo real):
Director de ventas: "Tengo un gran contrato activo, ¿puede darle un estado de 'básicamente empezando a cerrar'?"
Desarrollador: "¿Se refiere al porcentaje de finalización? ¿Tienes documentos financieros? Regístrelos en el sistema y el porcentaje se pondrá "
Managent: "No, todavía no ha empezado, sólo dale un estado.
es más complicado que sólo escribir por definición
esto es en realidad programar
mucha gente cree que entiende cómo hacerlo pero no sabe cómo hacerlo
ante las preguntas de alguien que sí lo hace, se confunden
codificación: por definición completa, es sólo un oficio
aquí ya - uno codificará una hora al día, otro día a la semana
uno escribirá 10kb refresco otro 100kb - el programa hará lo mismo
esto es sólo un el cliente está confundido - no entiende la palabra dinámica... o no entiende la estática, y entonces el programador actúa como profesor - educa al cliente
----
situación 2
el programador novato decidió que domina el lenguaje de programación y empezó a escribir
y entonces empieza el ciclo
https://forummql4.com/es/11099
el programa es sencillo
for(int i=0; i<362; i++)
{
Print("i=>", i);
}
pero en su registro
> lo probó, obtuvo el submuestreo a partir de 120, no de 0. Pero terminó con 361 en lugar de 362
---
esto es aún peor que un mal codificador - esto es una completa ignorancia del lenguaje y las tecnologías
y aquí ya un programador competente rechazará tal programador
la distribución está en... todo el mundo lo tiene...
Bueno, lo último me ha matado (diálogo real):
Director de ventas: "Tengo un gran contrato activo, ¿puede darle un estado de 'básicamente empezando a cerrar'?"
Desarrollador: "¿Se refiere al porcentaje de finalización? ¿Tienes documentos financieros? Regístrelos en el sistema y el porcentaje se pondrá "
Managent: "No, ni siquiera ha empezado, sólo le das el estatus".
¿Es 1C o algo similar en cuanto a las tareas que se realizan? Así que, qué demonios con él, el gerente, que consiga lo que quiere. Lo principal para el codificador aquí es entender que este estado no crea ninguna nueva publicación. Obviamente, sólo es necesario para informar al gerente, para que él mismo pueda ver cuál es su estado, y para que pueda informar a su jefe. Que el director piense que llevas medio mes sufriendo por él :)
Se asigna otro atributo lógico al contrato: "básicamente comenzando a cerrar", y se deja que el gestor establezca él mismo esta marca cuando lo considere oportuno (este tonto estado no lo determina obviamente el software, sino el usuario). Incluso si pide pintar un documento en verde para sí mismo - mientras no haya nuevos documentos financieros... ¿O me estoy perdiendo algo?
¿Es 1C o algo similar en cuanto a las tareas a resolver? Así que, qué demonios con él, el gerente, que consiga lo que quiere. Lo principal para el codificador aquí es entender que este estado no crea ninguna nueva publicación. Obviamente, sólo es necesario para informar al gerente, para que él mismo pueda ver cuál es su estado, y para que pueda informar al jefe. Que el director piense que llevas medio mes sufriendo por él :)
Se asigna otro atributo lógico al contrato: "básicamente comenzando a cerrar", y se deja que el gestor establezca él mismo esta marca cuando lo considere oportuno (este tonto estado no lo determina obviamente el software, sino el usuario). Incluso si pide pintar un documento en verde para sí mismo - mientras no haya nuevos documentos financieros... ¿O tal vez no he entendido algo?
Los programadores son personas racionales. Y su pensamiento es racional. La primera pregunta que surge es: "¿Por qué lo necesitamos?" Y si no hay una explicación racional desde el punto de vista del programador, hay fricción con el cliente.
Una vez conseguí un cliente decente, que sabía lo que quería y me explicó cómo debía funcionar. El resto son todos sobre el "botón rojo" :)
Sí, puedes hacer cualquier cosa por ti mismo, pero todo esto se suponía que se hacía en un sistema corporativo casero de contabilidad operativa para el trabajo realizado, desde el que se generan los asientos en la Cuenta SUN (que consolida los datos en todo el país), y la solución propuesta "sólo poner el estado" se suponía que afectaba a la previsión sin confirmación documentada. En resumen: "Uh hermano ... son sinvergüenzas". Lo principal es enviar al jefe de contabilidad a tiempo para que confirme la elegibilidad (por cierto, nunca regresó :-))
O tal vez no se entienda la diferencia entre las cuentas de gestión y las cuentas contables.