Discussão do artigo "Como criar uma Especificação de Requisitos para solicitar um indicador" - página 3

Novo comentário
 
Rashid Umarov:

Surpreendente. Podemos ver o que foi planejado no final? O cliente forneceu imagens inicialmente ou foram apenas palavras no início?

Rashid, há muitas páginas de discussão - é supérfluo aqui, e eu ainda não fiz o indicador - o prazo ainda não está se aproximando, e outras coisas são mais importantes.

 
Vasiliy Sokolov:

Na minha opinião, há muitos detalhes técnicos no artigo, que o cliente nunca conseguirá entender.

Vamos criar links para o artigo, como é nosso costume. Você poderá ver imediatamente a seção necessária e pular para ela, mesmo sem ler o artigo inteiro

Exemplo - MQL5.community - Guia do usuário

1. Configurações do perfil
2. Editor de mensagens
3. Favoritos
4. Mensagens privadas
5. Central de serviços
6. Trabalho e cálculos
7. Mercado
8. Sinais
9. RSS
10. Classificação
11 Armazenamento MQL5

 
Vasiliy Sokolov:

O principal para o cliente é ter uma ideia clara do que ele realmente quer. Para ter essa ideia, antes de trabalhar como freelancer, seria bom que o cliente tentasse fazer um esquema simplificado do indicador/especialista no Excel e fornecesse seu esquema com capturas de tela: como esse ou aquele sinal aparece no gráfico.

Um bom desejo. Embora me pareça que nenhum dos clientes faz isso.

 
Rashid Umarov:

Essa é uma boa observação. Embora eu não ache que nenhum dos clientes o faça.

Esse é o problema.

Nenhum deles pensa na lógica de funções, formalizações e o que é chamado para quê. Como se costuma dizer, se a vovó tivesse um avô, ela seria um avô.....

O cliente percebe o gráfico de forma 100% visual. Até mesmo o conceito de buffer é uma floresta escura para eles.

O cliente olha para o gráfico e quer que uma linha seja desenhada aqui, com esta altura e esta largura. As abordagens e explicações são muito específicas


Essa é a base na qual Rashid deve permanecer. Nem tente expandir os horizontes dele, porque ele ficará carregado e não fará nada do que você está tentando fazer com ele, porque ele precisa rever seus pontos de vista sobre a vida, e isso é muito tempo, e você precisa de um indicador para ontem.

---

É necessário deixar o cliente estritamente dentro da estrutura de seus conceitos (que ele já inventou ao se candidatar a freelancer).

E não apenas para o cliente, mas para o codificador , para fornecer esse modelo de questionário, no qual ele solicitará ao cliente dados sobre pontos e os escreverá de acordo com seu padrão.

E tudo além disso é pura comunicação, que (ao contrário da escrita de especialistas em comércio) não pode ser formalizada de forma alguma.

 

Quero dizer, aqui vai uma sugestão.

- Mudar a abordagem do conceito de ToR.
Agora, não se trata de uma correspondência ou txt ou documento com imagens, mas de um atributo inatingível do próprio aplicativo. Não é um documento anexado, mas um componente do serviço (na forma de um documento xml gerado).
É o TdR no aplicativo, elaborado com a ajuda de seu assistente e assinado por ambas as partes, será um documento.

Atitude do cliente
- se você realmente deseja carregar o cliente com informações sobre os recursos de MT, não deve exigir que o cliente preencha todos os campos ao criar um aplicativo. É suficiente obter dele o que ele conseguiu identificar em sua mente dentro da estrutura de conceitos algorítmicos e de MQL. Marque algumas opções de estilos, gráficos, etc.

Atitude do codificador
- o codificador é responsável por elaborar o TOR completo e formalizar todas as funções do cliente.
Ele se comunica com o cliente, preenche o componente TOR em detalhes, prescreve algoritmos e conceitos precisos para que sejam percebidos pelo cliente e aprovados. Ou seja, a criação de TOR é um processo de comunicação e aprovação. O TK faz parte do pedido.
Mesmo que o codificador se recuse a trabalhar, o TK trabalhado permanece no pedido e outro executor pode continuar a trabalhar com ele. O novo contratado não verá a correspondência, mas verá seu resultado - TOR.

---

É quando as ovelhas estão intactas e o cérebro do cliente não está quebrado.

O cliente está satisfeito - o codificador o entendeu e criou o TOR para ele.
O codificador está satisfeito - ele criou o TOR aprovado com a ajuda do assistente, e ele é aberto, não apertado.
O árbitro está satisfeito - não há necessidade de ler documentos de terceiros, mas apenas de visualizar o documento TOR concluído na solicitação.

No futuro, será possível coletar estatísticas sobre esses documentos, já que o próprio TOR agora é um documento formal.

 
o_o:

---

É necessário deixar o cliente estritamente dentro da estrutura de seus conceitos (que ele já criou para si mesmo ao se candidatar a freelancer).

E não apenas para o cliente, mas para o codificador , para fornecer esse modelo de questionário, de acordo com o qual ele solicitará ao cliente dados sobre itens e os escreverá de acordo com seu padrão.

E tudo além disso é pura comunicação, que (ao contrário da escrita de especialistas em comércio) não pode ser formalizada de forma alguma.

Devemos tentar. No processo de discussão deste tópico, acho que estou começando a mudar um pouco o conceito do artigo. Será dada mais ênfase ao desenho de figuras explicativas, serão dados alguns exemplos de TORs e, em seguida, o conteúdo atual será apresentado. Para aqueles que conseguirem ler os dois primeiros parágrafos.

 
o_o:

Quero dizer, proponho o seguinte

- mudar a abordagem do conceito de ToR.
Agora, não se trata de uma correspondência ou txt ou documento com imagens, mas de um atributo inatingível do próprio aplicativo. Não é um documento anexado, mas um componente do serviço (na forma de um documento xml gerado).
É o TdR no aplicativo, elaborado com a ajuda de seu assistente e assinado por ambas as partes, será um documento.

Duvido que essa seja a maneira de levar a humanidade ao paraíso. Para reinterpretar um clássico:

"Você não pode vender uma especificação (no sentido de que ninguém quer pagar por ela).

Mas você pode contratar um programador".

 
Rashid Umarov:

Duvido que essa seja a maneira de levar a humanidade para o céu. Reinterpretando um clássico:

"Você não pode vender uma especificação técnica (no sentido de que ninguém quer pagar por ela).

Mas você pode contratar um programador".

Não importa como dispensamos um codificador de escrever a TOR, mas no final é o codificador que a verifica, e a complexidade de sua verificação está incluída no orçamento.

Ou seja, o cliente acaba pagando por isso (paga pelo tempo do programador), pensando que se trata de uma programação tão cara, e não da formalização de sua TOR).

Rashid Umarov:

Será dada mais ênfase à criação de desenhos explicativos, alguns exemplos de TOR serão apresentados e, em seguida, o conteúdo atual será eliminado. Para aqueles que conseguem lidar com os dois primeiros pontos.

sim, mais capturas de tela ou micro gifs.

especialmente no assistente para tomar uma decisão por parte do cliente - que tipo de indicador especificar nos Termos de Referência, ou que tipo de linhas. Não apenas palavras, mas como será a aparência. Porque é assim que ele raciocina - o que verei no final e se corresponde à sua ideia.

 
o_o:

especialmente no assistente para tomar uma decisão por parte do cliente - que tipo de indicador especificar no ToR, ou que tipo de linhas. Não apenas palavras, mas como será a aparência. Porque é assim que ele raciocina - o que eu verei no final e se corresponde à sua visão

O Master TK ainda não foi planejado. Aqui seria o primeiro artigo útil para fazer e avaliar o resultado de sua aparência

 
Rashid Umarov:

O Master TK ainda não foi planejado. Aqui seria a primeira vez de criar um artigo útil e avaliar o resultado de sua aparência

Sim, por enquanto eu me referia a um artigo de dicas no mestre.

12345678
Novo comentário