Discutir los conflictos entre programadores y clientes. Un debate sobre las situaciones ambiguas entre el programador y el cliente, y una clasificación de los programadores más conflictivos. - 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
" Debate sobre los conflictos entre programadores y clientes. Un debate sobre las situaciones ambiguas entre un programador y un cliente, y una clasificación de los programadores más conflictivos.
No se puede inventar algo universal que elimine todos los conflictos. En el centro de los conflictos está la estupidez de los clientes. Por qué exactamente los clientes, porque los programadores han estado en el campo durante mucho tiempo.
Por supuesto, después de la décima o vigésima tarea la estupidez desaparece. Por supuesto, cada persona es diferente, para alguien se va durante la primera tarea, para alguien nunca se va.
Conseguir que el cliente primero se sumerja en el tema, leer el artículo CÓMO ESCRIBIR TK, aprender la terminología no es posible. La mayor mentira del siglo XXI - "El acuerdo de licencia decía. Estoy de acuerdo".
Educar al cliente en lugar de un trabajo específico en su TK, debe sentarse en el precio, ya se sienta allí. Ponerlo en el precio de nuevo no funcionará. Es ridículo quejarse de los precios bajos a los programadores de empleo, ellos son los que los fijan.
En general, no hay ningún conflicto global. Hay un trabajo rutinario. Siempre habrá trampas puntuales en un lado y en el otro.
¿Está hablando de todos sus RPT o está describiendo la jornada laboral del contratista tal y como la concibe?
" Debate sobre los conflictos entre programadores y clientes. Un debate sobre las situaciones ambiguas entre un programador y un cliente, y una clasificación de los programadores más conflictivos.
No se puede inventar algo universal que elimine todos los conflictos. En el centro de los conflictos está la estupidez de los clientes. Por qué exactamente los clientes, porque los programadores han estado en el campo durante mucho tiempo.
Por supuesto, después de la décima o vigésima tarea la estupidez desaparece. Por supuesto, cada persona es diferente, para alguien se va durante la primera tarea, para alguien nunca se va.
Conseguir que el cliente primero se sumerja en el tema, leer el artículo CÓMO ESCRIBIR TK, aprender la terminología no es posible. La mayor mentira del siglo XXI - "El acuerdo de licencia decía. Estoy de acuerdo".
Educar al cliente en lugar de un trabajo específico en su TK, debe sentarse en el precio, ya se sienta allí. Ponerlo en el precio de nuevo no funcionará. Es ridículo quejarse de los precios bajos a los programadores de empleo, ellos son los que los fijan.
En general, no hay ningún conflicto global. Hay un trabajo rutinario. Siempre habrá trampas puntuales en un lado y en el otro.
Pero todo esto no significa que alguien que vea círculos no pueda tener éxito en el mercado, mira el precio de los cuadros impresionistas.
Genio
El cuadro "Grito" solo
La propia lengua rusa es muy difícil de comprender lógicamente,
Esta es una representación hipotética de la jornada laboral del ejecutor.
Bueno, no todo es tan triste. Sí, el trabajo no lleva un pedido al día, a veces hasta 3, cada día durante varias semanas. Pero los constantes bugs y glitches creo que es demasiado.
No discuto que haya pedidos y clientes con los que los programadores tengan problemas de comprensión. Esto es el karma de tales órdenes o algo más, pero existe.
Los profesionales confirman que algunos pedidos son problemáticos y a veces incluso en una superficie fácil. A veces quiero rechazar el dinero y rechazar el pedido que te hace perder la cabeza y el tiempo.
Pero si tomamos una ejecución puramente técnica, entonces la programación de calidad sobre los TdR acordados (no tomemos tiempo para aprobar los TdR) puede tomar un máximo de 4 horas. Esto lo tomo como un TOR artificioso para un par de hojas de texto fino.
Entonces habrá cambios muy pequeños en 1-2 días, pero ya es polvo. Arreglarlas al final lleva un máximo de 30 minutos.
Si usted está trabajando con un programador en el estilo - hoy quiero una cosa, y mañana añadir una nueva al código sin terminar, o añadir una característica que proger cuelga y pensando en cómo pegarlo en el algoritmo TOR, por supuesto - los problemas en esta versión será.
Y su RPT se extenderá durante un mes o incluso seis meses. El resultado será una falsa opinión sobre la codificación como tal.
PS.
Siempre, recuerde, usted debe siempre antes de empezar a trabajar completamente discutir todos los detalles del algoritmo y todas las posibles combinaciones de casos de su trabajo. Inútil para el ejecutante, que en su RPT no encontrará un solo caso particular de fallo del algoritmo.
¡Siempre hay cosas nuevas! El cliente no los ve. Pero deben ser vistos por el contratista. Y antes de empezar la obra, informarle de ellas y discutirlas con usted. Pero es obligatorio antes de empezar a codificar.
Es mejor dedicar una semana a los TdR y luego escribir el código perfecto en un par de horas, que pasar meses buscando errores en los volátiles TdR. Ni usted ni el codificador disfrutarán de este proceso.
Incluso una frase pronunciada con una entonación diferente puede tener un significado y un contexto distintos.
Ahí es donde vas con esto. :)
Bueno, entonces puedes asumir con seguridad toda la responsabilidad del resultado del intérprete y de lo que te dará después de hablar con diferentes entonaciones en Skype :)
Usted mismo tiene la culpa si de todos los tipos de comunicación elige una transferencia de información por aire. Menos mal que no hay vídeo, o podrías haberte quejado de que la misma frase, pronunciada con una posición diferente del pie derecho y una oreja de soplillo puede significar cosas diferentes :)
Para ti, la recomendación nº 2.
Comuníquese con el intérprete sólo con el teclado. Si no puedes formarte bien una idea en la cabeza que no puedes plasmar en el papel, ¿de qué tipo de comprensión estamos hablando? Esto es una tontería.
Es un gran error pensar que se puede transmitir el significado profundo de una palabra con la entonación de la voz.
El significado de la palabra ya está en la palabra y no importa si es el tío con la voz ahumada o la abuelita sonriente en la cola del pan quien me mande a la mierda.
Siempre, recuerde, debe siempre antes del comienzo del trabajo discutir completamente todos los detalles del algoritmo y todas las posibles combinaciones de casos de su trabajo. Sin valor para el ejecutante, que no encontrará en su RPT ni un solo caso especial de fallo del algoritmo.
¡Siempre hay cosas nuevas! El cliente no los ve. Pero tienen que ser vistos por el contratista. Y antes del inicio de la obra, informarle de ellas y discutirlas con usted. Pero es obligatorio antes de empezar a codificar.
Es mejor dedicar una semana a los TdR y luego escribir el código perfecto en un par de horas, que pasar meses buscando errores en los volátiles TdR. Ni usted ni el codificador disfrutarán de este proceso.