Discutir os conflitos entre programadores e clientes. Uma discussão de situações ambíguas entre o programador e o cliente, e uma classificação dos programadores mais conflituosos. - página 7

 
É a noção do programador como um "homem de orquestra".
 

" Discutir os conflitos entre programadores e clientes. Uma discussão de situações ambíguas entre um programador e um cliente, e uma classificação dos programadores mais conflituosos.

Não se pode inventar algo universal que elimine todos os conflitos. No centro dos conflitos está a estupidez dos clientes. Porquê precisamente os clientes, porque os programadores já estão no terreno há muito tempo.

Claro que, após a décima ou vigésima tarefa, a estupidez desaparece. É claro que cada um é diferente, para alguém desaparece durante a primeira tarefa, para alguém nunca desaparece.

Fazer o cliente mergulhar primeiro no assunto, ler o artigo COMO ESCREVER TK, aprender a terminologia não é possível. A maior mentira do século XXI - "O acordo de licença lido. Estou de acordo".

Educar o cliente em vez de um trabalho específico no seu TK, deve sentar-se no preço, ele já se senta lá. Voltar a colocá-lo no preço não vai funcionar. É ridículo queixar-se de preços baixos a programadores de emprego, são eles que os fixam.

De um modo geral, não há conflito global. Há um trabalho de rotina. Haverá sempre fraudes pontuais de um lado e do outro.

 
sergeev:

Está a falar de todos os seus RPT ou está a descrever o dia de trabalho do empreiteiro tal como o prevê?


Esta é uma representação hipotética do dia de trabalho do empreiteiro.
 
Mischek:

" Discutir os conflitos entre programadores e clientes. Uma discussão de situações ambíguas entre um programador e um cliente, e uma classificação dos programadores mais conflituosos.

Não se pode inventar algo universal que elimine todos os conflitos. No centro dos conflitos está a estupidez dos clientes. Porquê precisamente os clientes, porque os programadores já estão no terreno há muito tempo.

Claro que, após a décima ou vigésima tarefa, a estupidez desaparece. É claro que cada um é diferente, para alguém desaparece durante a primeira tarefa, para alguém nunca desaparece.

Fazer o cliente mergulhar primeiro no assunto, ler o artigo COMO ESCREVER TK, aprender a terminologia não é possível. A maior mentira do século XXI - "O acordo de licença lido. Estou de acordo".

Educar o cliente em vez de um trabalho específico no seu TK, deve sentar-se no preço, ele já se senta lá. Voltar a colocá-lo no preço não vai funcionar. É ridículo queixar-se de preços baixos a programadores de emprego, são eles que os fixam.

De um modo geral, não há conflito global. Há um trabalho de rotina. Haverá sempre fraudes pontuais de um lado e do outro.

Vivemos numa época de divisão do trabalho, a especialização, mesmo numa indústria, está constantemente a reduzir-se e só se tornará mais difícil no futuro. Cada actividade desenvolve os seus próprios hábitos, a sua própria forma de comunicar. O que chama de obtuseness do cliente reflecte a sua atitude em relação à outra parte no contrato, mas não o verdadeiro estado de coisas. Para o mesmo cada pessoa é, em princípio, individual, mesmo tomando uma simples divisão em canais de percepção, alguém é melhor em perceber a informação visualmente, o outro em ouvir, o terceiro percebe perfeitamente o texto, mas isto não significa que em relação um ao outro sejam burros. A própria língua russa é muito difícil para a percepção lógica, tem muitas excepções às regras, ao contrário do inglês, onde a ordem das palavras determina muito, no nosso caso, mesmo uma frase pronunciada com entoação diferente pode ter um significado e contexto diferentes. Assim, conhece duas pessoas, um programador que tem as figuras da fórmula como um algoritmo, e uma pessoa que não é deste mundo, que vê a ordem de mudança de preço em círculos cor-de-rosa ou como o quadrado preto de Malevich. Mas só porque o seu cliente vê o mercado com os seus próprios olhos não significa que ele seja estúpido. Aqui aparecem os problemas de comunicação, e a tarefa do serviço liga usando a sua língua nativa russa, na qual muitas vezes a mesma frase pode ter significados diferentes, duas pessoas diferentes, podemos dizer de mundos diferentes, uma desenha círculos vermelhos e a outra grita estúpida dá-me a fórmula. Mas tudo isto não significa que alguém que vê círculos não possa ter sucesso no mercado, olhe para o preço das pinturas impressionistas.
 
Bormotun:
Mas tudo isto não significa que alguém que vê círculos não possa ter sucesso no mercado, olhe para o preço das pinturas impressionistas.
Génio
 
Mischek:
Génio

A pintura "Scream" sozinha

 
Bormotun:
A própria língua russa é muito difícil de compreender de forma lógica,
Ah, sim. Eu sou o seu trompete de cagalhão de casa significa vir em tchau.
 
Bormotun:
Esta é uma representação hipotética do dia de trabalho do executor.

Bem, nem tudo é tão triste. Sim, o trabalho não leva uma encomenda por dia, por vezes até 3, todos os dias durante várias semanas. Mas os bugs e falhas constantes, penso que é demasiado.

Não defendo que haja encomendas e clientes com os quais os programadores tenham dificuldade em compreender. Este é o carma de tais ordens ou outra coisa qualquer, mas ele existe.
Os profissionais confirmam que algumas ordens são problemáticas e por vezes até numa superfície fácil. Por vezes, quero recusar o dinheiro e recusar a ordem que apenas lhe explode a mente e leva tempo.

Mas, se for necessária uma execução puramente técnica, então a programação de qualidade sobre os ToR acordados (não vamos demorar tempo a aprovar ToR) pode demorar no máximo 4 horas. Isto estou a levar um TOR inflado em algumas folhas de texto fino.
Depois haverá mudanças muito pequenas em 1-2 dias, mas já é pó. A sua fixação no final demora um máximo de 30 minutos.

Se estiver a trabalhar com um programador no estilo - hoje quero uma coisa, e amanhã acrescentar uma novidade ao código inacabado, ou acrescentar uma funcionalidade que o proger pendura e pensa em como o colar no algoritmo do TOR, claro - os problemas nesta versão serão.
E o seu RPT irá alongar-se durante um mês ou mesmo seis meses. Como resultado, obterá uma opinião falsa sobre a codificação enquanto tal.

PS.

Lembre-se sempre, antes de começar a trabalhar deve sempre discutir completamente todos os detalhes do algoritmo e todas as combinações possíveis de casos do seu trabalho. Inútil para o artista, que no seu RPT não encontrará um único caso particular de falha do algoritmo.

Há sempre coisas novas! O cliente não os vê. Mas devem ser vistas pelo empreiteiro. E antes do início dos trabalhos, informe-o sobre eles e discuta-os consigo. Mas é obrigatório antes do início da codificação.

É melhor passar uma semana no ToR e depois escrever o código perfeito num par de horas, do que passar meses à procura de bugs no volátil ToR. Nem você, nem o codificador irão desfrutar de tal processo.

 
Bormotun:
Mesmo uma frase pronunciada com uma entonação diferente pode ter um significado e contexto diferentes.

É aí que se vai com isto. :)

Bem, então pode assumir com segurança a total responsabilidade pelo resultado do artista e pelo que ele lhe dará depois de falar com diferentes entoações no Skype :)

A culpa é sua se, de todos os tipos de comunicação, escolher uma transferência de informação por via aérea. Graças a Deus não há vídeo, ou poderia ter-se queixado que a mesma frase, pronunciada com uma posição diferente do pé direito e uma orelha saliente pode significar coisas diferentes :)

Para si, recomendação nº 2.

Comunicar com o intérprete apenas com o teclado. Se não consegue formar correctamente uma ideia na sua cabeça que não a possa pôr no papel, então de que tipo de entendimento estamos a falar? Isto é um disparate.
É um equívoco muito grande se pensar que pode transmitir o significado profundo de uma palavra com entoação na sua voz.

O significado da palavra já está na palavra e não importa se é o tio com a voz fumada ou a avó sorridente na fila do pão que me vai dizer para me ir foder.

 
sergeev:


Lembre-se sempre, deve sempre, antes do início do trabalho, discutir completamente todos os detalhes do algoritmo e todas as combinações possíveis de casos do seu trabalho. Inútil para o artista, que não encontrará no seu TOR um único caso especial de falha do algoritmo.

Há sempre coisas novas! O cliente não os vê. Mas eles têm de ser vistos pelo empreiteiro. E antes do início dos trabalhos, informe-o sobre eles e discuta-os consigo. Mas é obrigatório antes do início da codificação.

É melhor passar uma semana no ToR e depois escrever o código perfeito num par de horas, do que passar meses à procura de bugs no volátil ToR. Nem você, nem o codificador irão desfrutar de tal processo.


Concordo absolutamente, concordo com cada palavra e marquei a vermelho exactamente o que encontrei no meu trabalho e isso levou a um resultado lamentável. Se fosse assim na vida real, eu não teria escrito uma única linha aqui. Além disso, não tenho experiência em comunicar em fóruns, apenas me fartei disso.
Razão: