Asesor rápidamente (1-5 horas) por 10 dólares.Un guión por 5 dólares. - página 9
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
La práctica ha demostrado que la autopromoción ha matado más de un hilo de este tipo. Sólo puedo aconsejar un procedimiento sensato para encontrar un programador. EN MI OPINIÓN.
1. Lea el artículo "Asesor experto a la orden. Instrucciones para el comerciante" escritas por el legendario komposter. Se trata de una guía práctica para preparar la RPT.
2. Busca en el foro programadores (no anuncios de pedidos), lee las discusiones, ve cómo se comporta la gente.
3. Haz una lista de candidatos que te gusten (los que sean simpáticos, se expresen correctamente y con precisión, tengan una larga experiencia en el foro con una amplia lista de guiones/artículos serios publicados).
4. Redactar los términos de referencia y ponerse en contacto con los candidatos, tras un acuerdo preliminar para enviar los términos de referencia para la estimación de los costes.
5. Elige uno y agradece al resto.
En mi experiencia, las autoridades indiscutibles son komposter e Integer (pido disculpas a los demás profesionales, es que no me he encontrado).
El algoritmo es bueno, pero un problema: cuanto más "incondicional" sea el autoite, más caros serán sus servicios :) Eso es tratar de encontrar un compromiso razonable.
Aunque probablemente haya una pizca de verdad en el hecho de que el tacaño paga muchas veces...
Varias veces, con mi modesta experiencia en programación, he accedido a cumplir pedidos de diseños sencillos y elementales.
La impresión es inequívoca. Por lo general, los clientes tienen una idea muy pobre de lo que quieren obtener al final.
Y conseguir que interpreten el pliego de condiciones: ¡a veces lleva más tiempo que la propia redacción del consejo! Los términos de referencia (sin ironía) son a veces casi imposibles de entender.
Por lo general, el propio cliente desconoce por completo lo que quiere...
De un "TdR": Cuando el horario de la línea A es inferior al de la línea B...
Más comunicación en la voz:
Yo: ¿un poco es cuánto y en qué?
Zach: ¿Eres idiota, no sabes lo que es un poco?
El algoritmo es bueno, pero hay un problema: cuanto más "incondicional" sea un auto, más caros serán sus servicios :) Así que tratas de encontrar un compromiso razonable.
Aunque probablemente haya algo de verdad en el hecho de que un avaro paga muchas veces...
Un algoritmo que ha sido probado durante generaciones. Incluso en este hilo, está claro que la "comunicación desordenada" conduce a mayores pérdidas de dinero y nervios.
Y el ahorro debe hacerse con habilidad: cosas sencillas que puedes hacer tú mismo, cosas opcionales que puedes encargar por un módico precio, pero los griales potenciales para dar a los graduados.
Te mostrarán de forma inteligente, razonable y correcta que estás equivocado de nuevo y recordarás muy bien la lección porque ha costado un buen dinero.
¿No sería más fácil decirle cuánto está dispuesto a pagar, junto con los términos de referencia?
por el trabajo de un programador.
Por regla general, el propio cliente no entiende del todo lo que quiere...
De un "ToR": Cuando el horario de la línea A se queda un poco corto con respecto a la línea B...
Más comunicación por voz:
Yo: ¿un poco es cuánto y en qué?
Zach: ¿eres idiota, no sabes lo que es un poco?
no es un objetivo, pero sí un consejo: si ves que el propio cliente no sabe lo que quiere, sé más tolerante: ofrécele varias opciones. ¡deja que elija entre ellas!
no es un objetivo, pero sí un consejo: si ves que el cliente no sabe lo que quiere, sé más tolerante: ofrécele varias opciones para elegir. ¡deja que elija entre ellas!
Así es como lo hacen los codificadores... 2-3 variantes y luego el cliente decide.
Puede que haya quien no quiera molestarse en "tirar de las pinzas de TK".
no es un objetivo, pero sí un consejo: si en su comunicación ve que el cliente no sabe lo que quiere, sea más tolerante: ofrézcale varias opciones a la vez. ¡deje que elija entre ellas!
Definitivamente, ¡no deberías hacer eso!
"Porque" en cualquier resultado "a ras" (y no habrá otro) el culpable será siempre el programador.
Con todas las consecuencias...
Definitivamente, ¡no deberías hacer eso!
"Porque" en caso de cualquier resultado "fallido" (y no habrá otro) la culpa será siempre del programador.
Con todas las consecuencias...
¡no entiendes! ;-) si el cliente no puede formular la condición por sí mismo, puedes simplemente darle a elegir entre varias opciones (basadas en tu experiencia de desarrollo, formalización). y él puede decirte si se ajusta a su "confusa descripción" o no. si dice que una opción se ajusta, ¡entonces déjalo! Pero si empiezas a escribir sin formalizar la tarea (en términos de cumplimiento de la "descripción verbal del cliente"), entonces - sí, estoy completamente de acuerdo contigo - no importa cómo escribas el programador, seguirá siendo malo, tendrás que rehacerlo 2-3-4-5 veces.
Eh, es difícil ser un codificador después de todo. Y también es difícil que un cliente se comunique con un programador si éste (el programador) es "tan idiota que no sabe lo que significa 'un poco'". Y lo curioso es que para formular la RPT correctamente, la mente del cliente tiene que estar girada de la misma manera que la de ese codificador idiota.