Consultor rápido (1-5 horas) por $10,00 por um roteiro de $5. - página 9
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
A prática demonstrou que a autopromoção matou mais de um desses fios. Só posso aconselhar um procedimento sensato para encontrar um programador. IMHO.
1. Leia o artigo "Expert Advisor to order".Instruções para o comerciante" escrito pelo lendário komposter. Este é um guia prático para preparar o TOR.
2. Procure no fórum em busca de programadores (não de anúncios para pedidos), leia as discussões, veja como as pessoas se comportam.
3. Faça uma lista dos candidatos que você gosta (aqueles que são simpáticos, se expressam corretamente e com precisão, têm uma longa experiência no fórum com uma grande lista de manuscritos/artigos sérios publicados).
4. Elaborar os Termos de Referência e contatar os candidatos, após acordo preliminar para enviar os Termos de Referência para a estimativa de custos.
5. Escolha um e agradeça o resto.
Em minha experiência, as autoridades indiscutíveis são a komposter e a Integer (peço desculpas aos outros profissionais, simplesmente não encontrei).
Algoritmo é bom, mas um problema: a autoite "incondicional", quanto mais caros são seus serviços :) Isso é tentar encontrar um compromisso razoável.
Embora provavelmente haja um grão de verdade no fato de que o mesquinho paga muitas vezes.
Várias vezes, com minha modesta experiência em programação, concordei em atender pedidos para os projetos mais simples e básicos.
A impressão é inequívoca. Como regra geral, os clientes têm uma idéia muito ruim do que querem obter no final.
E para fazê-los interpretar os termos de referência - às vezes leva mais tempo do que a redação real da dica! Os termos de referência (sem ironia) às vezes são difíceis de serem extraídos!
Normalmente o próprio cliente desconhece completamente o que ele quer ...
De um "ToR": Quando o cronograma da linha A fica muito aquém da linha B...
Mais comunicação na voz:
Eu: um pouco é quanto e em que ?
Zach: Você é um idiota, não sabe o que é um pouco?
O algoritmo é bom, mas um problema: quanto mais "incondicional" for um auto-item, mais caros são seus serviços :) Portanto, você tenta encontrar um compromisso razoável.
Embora provavelmente haja alguma verdade no fato de que um avarento paga muitas vezes...
Um algoritmo que tem sido testado por gerações. Mesmo a partir deste fio, fica claro que a "comunicação casual" leva a maiores perdas de dinheiro e nervosismo.
E a economia deve ser feita com habilidade: coisas simples para fazer você mesmo, coisas opcionais para pedir por uma taxa modesta, mas os grãos em potencial para dar graduação.
Eles lhe mostrarão de forma inteligente, razoável e correta que você está errado novamente e você se lembrará muito bem da lição porque custou bom dinheiro.
Não seria mais fácil dizer-lhe quanto você está disposto a pagar, juntamente com os termos de referência?
para o trabalho de um programador.
Como regra, o próprio cliente não entende totalmente o que quer.
De um "ToR": Quando o cronograma da linha A cai um pouco abaixo da linha B...
Comunicação adicional por voz:
Eu: um pouco é quanto e em que ?
Zach: você é um idiota, você não sabe o que é um pouco?
não é um alvo, mas ainda assim uma dica - se você vir que o próprio cliente não sabe o que quer, seja mais tolerante: ofereça uma escolha de várias opções. deixe-o escolher entre elas!
não é um alvo, mas ainda assim um conselho - se você vê que o cliente não sabe o que quer, seja mais tolerante: ofereça várias opções para escolher. deixe-o escolher entre elas!
É assim que os codificadores fazem ... 2-3 variantes e depois o cliente decide.
Pode haver aqueles que não querem se preocupar com "pinças puxando TK".
não é um conselho, mas ainda assim um conselho - se você pode ver em sua comunicação que o próprio cliente não sabe o que quer, seja mais tolerante: ofereça várias opções ao mesmo tempo. deixe-o escolher entre elas!
Definitivamente - você não deveria fazer isso!
"Pois" em qualquer resultado "nivelado" (e não haverá outro) o culpado será sempre o programador.
Com todas as conseqüências...
Definitivamente - você não deveria fazer isso!
"Para" no caso de qualquer resultado "falhado" (e não haverá outro) o programador será sempre o culpado.
Com todas as conseqüências...
você não entende! ;-) se o cliente não puder formular ele mesmo a condição, você pode simplesmente dar a ele uma escolha de várias opções (com base em sua experiência de desenvolvimento, formalização). e ele pode dizer se ela se encaixa ou não em sua "descrição confusa". se ele diz que uma opção se encaixa, então deixe-o! Mas se você começar a escrever sem formalizar a tarefa (em termos de conformidade com a "descrição verbal do cliente"), então - sim, eu concordo completamente com você - não importa como você escreve o programador, ainda será ruim, você terá que refazê-la 2-3-4-5 vezes.
Afinal, é difícil ser um codificador. E também é difícil para um cliente se comunicar com um codificador se ele (o codificador) for "tão idiota que não sabe o que 'um pouquinho' significa". E o engraçado é que para formular o TOR corretamente, a mente do cliente tem que ser voltada da mesma forma que a daquele codificador idiota.