Esses sinais são de um desenvolvedor ruim? [fechadas]

36

Eu costumava culpar as especificações de clientes em troca de podridão de código, não percebendo que os modelos de negócios mudam e meu trabalho é desenvolver de uma maneira adaptável. Agora vejo isso como um sinal de um desenvolvedor ruim (eu mudei!).

Mas agora vejo outras 'whinges' em mim. Algumas vezes recentemente eu me vi dizendo 'é como tentar encaixar uma estaca quadrada em um buraco redondo', e também me vejo culpando a indecisão do cliente por um projeto que não está progredindo.

Há sinais de que devo procurar onde devo mudar minha atitude? O cliente está sempre certo ou às vezes me sinto justificado em ficar frustrado?

    
por Paul T Davies 06.10.2011 / 15:41
fonte

10 respostas

55

Eu não diria que você é um desenvolvedor ruim. Estar ciente dos problemas já o leva além dessa definição.

Alteração de requisitos. Isso é um dado. Um bom desenvolvedor precisa levar isso em conta. Muitas técnicas modernas de programação ajudam a lidar com isso.

Manter-se fiel à especificação original não é realista. Também não é realista mudar os requisitos o tempo todo.

O cliente definitivamente não está sempre certo. É 'certo' mais frequentemente do que queremos que ele seja, embora (como em, tente acomodá-lo se ele não estiver totalmente desligado). Mas quando você vê-lo dirigindo o projeto na direção errada, tente defender as coisas que você acha que estão certas.

Não há regras rígidas sobre essas coisas, e mesmo desenvolvedores bons e experientes não alcançaram o perfeito 'Zen'. A única abordagem errada é não tentar melhorar isso.

    
por 06.10.2011 / 15:52
fonte
38

Existem casos em que é o cliente. Mas esse é o seu problema também

Há casos em que é o desenvolvedor e há casos em que é o cliente. Mas, geralmente, são ambos o problema, então uma atitude de culpar-se tende a ser mais bem-sucedida, porque erra no lado da resolução de problemas, em vez de apontar o dedo impotente. Portanto, você frequentemente encontrará em desenvolvedores mais experientes.

Uma atitude ainda melhor é IMHO para olhar para ele sem culpa: "é culpa dos clientes que eu tenho código ruim, porque ele sempre muda requisitos" então se torna "esse cliente está descobrindo o que ele quer, então feedback, prototipagem rápida e flexibilidade é mais importante que a integralidade, robustez e velocidade ".

Tipo de uma mente zen: não julgue, apenas veja como é.

    
por 06.10.2011 / 16:25
fonte
13

Primeiro, um cliente não sabe o que quer até vê-lo. Isso é parte do apelo das pequenas iterações do paradigma Ágil, com grande envolvimento do cliente. Segundo, não espere que um produto seja "completo" quando você estiver com o código completo.

A Microsoft emprega um produto chamado 'Watson' (a mensagem de envio de feedback que você recebe quando o Windows é executado) para rastrear problemas diretamente para um cliente. A rastreabilidade é uma boa maneira de rastrear os problemas até os usuários que os experimentam. Você pode obter rastreabilidade perguntando. Ou, se você tiver recursos, integre a funcionalidade ao (s) produto (s). A chave é acompanhar os problemas / melhorias para que possam ser abordados.

Finalmente, o cliente certo pode ser inconstante. Nesses casos, tento me concentrar no segredo do iceberg .

    
por 06.10.2011 / 15:52
fonte
5

A mudança de requisitos é um fato difícil da vida; mas a putagem do código não é causada por isso.

A corrupção de código ocorre quando há algumas partes do seu código que você não pratica com frequência; Então, quando você faz algumas alterações que "não devem afetar qualquer outra coisa", você pode introduzir bugs. Em outras palavras, o código que não vê a luz do dia decompõe-se lentamente e você não pode dizer quando parou de funcionar.

Sim, a culpa é sua e não dos seus usuários.

A solução real? teste todo seu código com freqüência. Claro, a melhor maneira é ter testes automatizados com boa cobertura.

    
por 06.10.2011 / 15:58
fonte
4

A indecisão do cliente pode ser um grande problema e, se você não for o responsável pelo gerenciamento do relacionamento com o cliente, poderá ser muito difícil lidar com ele. Você poderia conversar com a pessoa que lida com o cliente e explicar com calma que o progresso não pode acontecer até que o cliente tome uma decisão. Se você é responsável pelo relacionamento com o cliente, você precisa dizer ao cliente que ele precisa tomar uma decisão antes que o projeto possa continuar. Pode não ser que sua atitude precise de uma revisão, apenas um minuto de meditação para se acalmar. ;)

    
por 06.10.2011 / 15:51
fonte
4

Javier faz um bom argumento que as exigências em mudança são um fato difícil da vida. Eu também fico frustrado com essas situações, pois muitas vezes me vejo trabalhando em um produto onde o desenvolvedor tem que tomar decisões. Minha opinião costumava ser "Por que o gerenciamento não pode descobrir isso com o cliente?", Ou "Por que começamos este projeto se o cliente não sabe o que queria?", "É muita dor de cabeça quando eles mudam assim no final do desenvolvimento ".

Fato simples: isso sempre ocorrerá , não apenas na programação / desenvolvimento de software, mas em todas as etapas da vida. O mundo seria simplesmente um lugar muito chato e muito diferente se as pessoas nunca mudassem de ideia, nunca se adaptassem, nunca se tratassem de mudanças. As pessoas tendem a olhar para o que lhes é dado e a melhorar. Você não faz a mesma coisa com o seu código? Se eu tenho um bloco de código com o qual não estou feliz (é ineficiente, confuso), vou melhorar. (O sistema operacional reclama de mim? ... às vezes, se eu estou usando um determinado SO sem nome, mas geralmente não)

Como programadores, precisamos aproveitar as oportunidades para melhorar as coisas, e não ficar deprimido ou incomodado com elas. Aproveite a oportunidade para conversar com as pessoas, melhorar seu estilo, melhorar sua ética de trabalho, abordar as coisas com a mente aberta, esforçar-se para ser melhor do que era ontem. Avance em sua carreira e não se acomode com muita facilidade.

Eu entendo que nem todos concordarão com essa resposta, mas acho que é importante que as respostas a essa pergunta abranjam uma perspectiva mais ampla.

    
por 06.10.2011 / 16:15
fonte
2

Quando você está interagindo com um cliente, você não está programando; você está aprendendo e ensinando.

Mantenha os clientes informados e os instrua sobre o processo. Mudança vai acontecer. Deixe-os saber que você tentará implementá-los, mas isso vai custar mais. Deixe que eles decidam.

Não entre em detalhes técnicos, mesmo quando a pergunta que eles fazem é de natureza técnica. Você fica tentado porque vai se sentir um pouco defensivo e vai querer enfrentar um desafio / ter seu geek-on. Não faça isso; eles não se importam com os detalhes e param de ouvir depois de 45 segundos.

Se você não informou antecipadamente, não espere que eles saibam sobre padrões e práticas recomendadas do setor ou qualquer outra desculpa para fazer o que você faz. Eu odeio quando não vejo uma taxa até o final apenas para que o vendedor me diga que é padrão na indústria. Não se deveria esperar que eu soubesse disso. Minha resposta é: "Também estou me sentindo um idiota como padrão?"

Quando você está com um cliente, preste mais atenção a ele do que qualquer pessoa ou qualquer outra coisa na sala. Cães domesticados são gênios nisso; especialmente se você tem comida.

    
por 07.10.2011 / 16:33
fonte
1

É um mau gerenciamento de requisitos ou uma má análise. Seu analista de negócios (se você tiver um) ou quem quer que receba os requisitos precisa sentar-se com o cliente e tentar obter todos os requisitos, mesmo os que o cliente pode não pensar. Os clientes geralmente não sabem tudo o que querem, um ótimo analista de negócios os ajudará a descobrir tudo.

    
por 06.10.2011 / 16:01
fonte
1

É por isso que você deve sempre obter uma configuração do Documento de requisitos de negócios e ser aprovado antes de qualquer aplicativo ir além da fase de criação de protótipos / pesquisa.

Agora, a ideia de que este documento é realmente final é falha, mas isso deve ajudá-lo a ter uma ideia melhor do que o cliente realmente deseja. E, desde que você escreva seu código com a manutenção em mente, poderá minimizar os problemas.

E se você precisar de uma desculpa para recorrer, poderá culpar os atrasos no BRD, que o cliente assinou, não incluindo tal e tal recurso, etc.

(Claro, isso é apenas uma desculpa para o caso de você precisar. Você deve sempre planejar mudar alguma coisa )

    
por 06.10.2011 / 20:27
fonte
1

Na citação de Emerson, "Uma consistência tola é o hobgoblin das mentes pequenas ..." a palavra mais negligenciada é tola . A consistência não é negociável em certas situações, mas geralmente substitui o pensamento crítico e a análise.

Por um lado, muitos modelos de desenvolvimento são projetados especificamente para ajudar no ambiente que você está descrevendo; Então, se você está tendo que violar seu modelo, então você não o está implementando em primeiro lugar, ou você tem o modelo errado.

Mas, por outro lado, se você tem uma justificativa fundamentada e justificável para violar suas regras, e você pode mostrar que seu método desonesto produz código mais limpo e mais sustentável, então você não deve ter medo de tomar a rota sensata. .

    
por 06.10.2011 / 22:38
fonte