Qual é o relacionamento adequado entre o desenvolvedor de software e o cliente comercial?


10

Os profissionais de TI são especialistas confiáveis ​​com os ativos de TI de uma empresa ou organização. Como profissionais de confiança, temos responsabilidades que vão além do que um cliente que não é de TI pode entender ou estar ciente. Então, acho que o relacionamento adequado entre um profissional de TI e seus clientes internos / externos é mais parecido com o médico e o paciente do que com um servo e mestre. Estou certo?

Aqui está uma analogia para se pensar. Um paciente insiste que sua perna precisa ser amputada. O médico discorda, mas o paciente não pode ser persuadido. O médico deve amputar a perna apenas para satisfazer o paciente?

Outra analogia. Um cliente deseja que um engenheiro civil construa uma ponte para um design inseguro. Mesmo quando o engenheiro explica que não é seguro, o cliente não acredita nele. O engenheiro deve construir a ponte de qualquer maneira?

Eu acho que a resposta certa nessas duas analogias é NÃO. O profissional médico e o profissional de engenharia devem estar em uma posição de confiança e devem exercer seu próprio julgamento, mesmo diante da desaprovação do paciente / cliente. O mesmo não deveria se aplicar aos profissionais de TI quando o profissional de TI está qualificado para tomar a decisão, mas o cliente não está?


2
Em uma conferência, ouvi uma vez um palestrante dizer: "Faça o que fizer, não permita que o cliente tenha acesso direto ao seu programador líder. Se você o fizer, ele literalmente o estuprará". Eu acho que isso seria o relacionamento errado entre um desenvolvedor de software e o cliente e o pior uso que eu já ouvi.
Jon Hopkins

E aqui no meu trabalho é um princípio fundamental que o cliente sempre tenha acesso direto ao programador líder!
Frank Shearar

Para pequenos valores de "literalmente", presumivelmente?
Mawg diz que restabelece Monica

Respostas:


9

É um pouco mais complicado do que nos seus exemplos. Isso ocorre porque, em muitos casos, o desenvolvedor de software é especialista em assuntos relacionados à TI (ou seja, programação, design de banco de dados etc.), mas o cliente comercial é especialista no domínio do problema. Nesses casos, o relacionamento adequado é o de dois especialistas em diferentes áreas que trabalham juntos para criar uma boa solução.

De qualquer forma, como qualquer bom artesão, o desenvolvedor de software é obrigado a avisar o cliente quando ele deseja coisas inapropriadas. Se você pedir ao seu pintor e decorador para colocar papel de parede no banheiro, ele também é obrigado a avisar que isso não vai funcionar bem. Mas quando o cliente teimosamente insiste em sua má ideia, é aceitável que ele assine um formulário "você foi explicitamente avisado" e implemente o que ele deseja (desde que não haja risco à saúde, risco legal etc.).


11
+1 Eu também acho que amputar uma perna sem razão e construir uma ponte insegura é muito mais perigoso do que entregar um aplicativo que não atenda às necessidades reais do cliente. No entanto, como disse a dportas, o papel do especialista em TI é alertar o cliente sobre isso. E então é apenas ética. Um bom advogado não aconselhará seu cliente a processar a outra parte se ele tiver certeza de perder. (mas ganhe sua taxa por hora)

11
+1 - Vi pelo menos tantas instâncias do desenvolvedor que realmente não entendem o negócio dos clientes quanto as identifique corretamente o cliente solicitando a coisa errada e identificando o que é realmente necessário . Ou seja, eles freqüentemente identificam corretamente que há um problema com o que foi sugerido, apenas a solução deles ainda é falha. A abordagem correta é o respeito mútuo pelo conhecimento do domínio um do outro e uma discussão aberta sobre o problema em potencial e as soluções em potencial. Geralmente, os clientes estão dispostos a ouvir.
Jon Hopkins

11
Então, onde vocês trabalham para que o "cliente comercial" seja realmente uma expectativa no domínio do problema? Muitas vezes eu descobri que não é o caso ...
CaffGeek

Chade: Na minha experiência, algumas empresas de software se concentram na venda para o gerenciamento de nível superior, o que obriga o gerenciamento de nível intermediário a implementar o que soa bem no papel. Nessas empresas, você raramente encontra "clientes comerciais", que também são especialistas no domínio do problema, porque há uma tendência de que o mesmo gerente que assinou o contrato continue sendo a pessoa de contato, faça ou não sentido. Outras empresas preferem vender para o departamento em questão, portanto a pessoa de contato principal geralmente conhece seu trabalho.
user281377

1

Nos exemplos médico e engenheiro, o profissional é um consultor que se recusa a prestar um serviço. Em uma loja de TI, você não é.

Somos funcionários, não consultores, por isso estamos sujeitos à regra de ouro: quem nos dá as regras de ouro. Programadores que ignoram que estão sendo arrogantes e tolos. Ouvi inúmeras reclamações sobre isso de empresários que estão cansados ​​da equipe de TI que não explicam suas decisões a ninguém fora do sacerdócio insular e que dispensam pedidos que todo mundo fora da organização considera perfeitamente razoável. Eu já vi gerentes de TI demitidos por esse tipo de coisa.

Como funcionário, seu equivalente a um consultor que se recusa a prestar um serviço é coberto por uma citação de Napoleon Bonaparte:

Todo comandante responsável pela execução de um plano que considere ruim ou desastroso é criminoso. Ele deve apontar as falhas, insistir para que isso mude e, finalmente, renunciar ao invés de ser o instrumento da destruição de seus próprios homens.

Você tem que escolher suas batalhas. O que você foi convidado a fazer é tão hediondo e antiético que você prefere sair? Caso contrário, explique o problema às partes interessadas e negocie algo razoável, ou apenas faça-o.

E não faça coisas nas quais você não comprou. As pessoas que fazem isso são chamadas de "canhões soltos".

Aliás, eu larguei um emprego porque eles mataram um projeto e eu pensei que era uma jogada realmente estúpida. Alguns meses depois que saí, eles chegaram a um acordo comigo e me pediram para voltar como empreiteiro para fazer o projeto, mas eu já estava comprometido em outro lugar.


2
Muitos desenvolvedores são consultores! Sou um.
Amir Rezaei

11
Sou consultor!
Nvogel

Além disso, engenheiros e médicos podem ser funcionários. Tenho certeza de que todas as grandes ferrovias têm engenheiros civis na folha de pagamento, para quando desejam construir ou modificar uma ponte.
David Thornley

4
Fui consultor em período integral de 1991 a 2006 e retornei a ele em período integral em julho. Eu acho que se um cliente quer me pagar para fazer algo estúpido, mas não ético ou perigoso, e insiste em minhas objeções ... ei, é o dinheiro deles a desperdiçar. Normalmente, eu acho que meus clientes sabem mais sobre os negócios do que eu, então as coisas que eles querem que pareçam loucas no começo fazem sentido depois que eu entender mais. Acho que me pedem para fazer coisas idiotas menos como consultor pago por hora do que como funcionário cuja hora extra é "gratuita" para o empregador.
Bob Murphy

1

Os médicos juram "não fazer mal" e são legalmente obrigados a colocar o melhor interesse do paciente em primeiro lugar . Um médico que realizasse uma operação desnecessária e prejudicial (mesmo que o paciente exigisse) estaria se abrindo para uma ação por negligência médica e poderia perder sua licença.

Da mesma forma, um engenheiro civil, responsável por um projeto de construção, tem uma obrigação legal de garantir que cumpra todos os códigos de construção aplicáveis. Assim como o médico, um engenheiro que faz o que é sugerido na pergunta provavelmente enfrentaria uma ação legal.

Isso é muito diferente da situação de um desenvolvedor de software ser solicitado a fazer algo que eles sabem que é impraticável. Não há ramificações legais para assumir um projeto, mesmo se você souber que é essencialmente um desperdício de dinheiro.

Dito isto, um desenvolvedor de software deve sempre fornecer seus melhores conselhos em qualquer projeto. No entanto, se as pessoas que pagam as contas não estão dispostas a ouvir e insistir em um curso de ação imprudente, o desenvolvedor não tem obrigação moral ou legal de recusar.


2
Pode ser que um projeto de software ponha em risco a vida e os membros. Como em um banco de dados de registros médicos ou em um sistema de controle de uma aeronave, por exemplo. Muito mais provável, porém, que possa haver fatores éticos ou regulatórios que sejam a preocupação legítima dos profissionais de TI - como regras de privacidade e proteção de dados ou leis de IP.
Nvogel

@dportas Isso é possível, mas se houver, provavelmente existem leis e regulamentos que regem sua construção e certificação. Claramente, você nunca deve infringir a lei para seu cliente. Entretanto, isso raramente é um problema e, a julgar pelos exemplos citados pelo OP, não é o que estava sendo perguntado.
Kris

0

O mesmo não deveria se aplicar aos profissionais de TI quando o profissional de TI está qualificado para tomar a decisão, mas o cliente não está?

Na minha opinião SIM!

Se você vai ter um longo relacionamento com seu cliente.


0

Minha sugestão nessa situação será avisar o cliente por meio de comunicação por escrito e manter uma cópia (e-mail, qualquer acordo). Se o cliente insistir, vá em frente e faça-o (às vezes é conhecido como desacordo e comprometimento). Apenas certifique-se de que, se algo ruim acontecer, você possa se defender adequadamente.


0

A principal diferença é o licenciamento. Médicos e engenheiros civis possuem licenças profissionais e precisam deles para realizar seu trabalho e ganhar a vida, e também têm responsabilidade pessoal legal por mais coisas.

Isso pode exercer mais pressão sobre médicos e engenheiros, quando forçado a fazer algo que possa causar riscos pessoais e profissionais, mas oferece mais resistência, já que eles podem argumentar que não podem fazer algo por causa da ética profissional, e que eles perderão suas licenças se o fizerem. Uma ameaça de demitir um engenheiro civil por se recusar a assinar um plano perde força quando a conseqüência da assinatura é que o engenheiro perderá sua licença e não poderá mais trabalhar no campo.

Isso está conectado aos requisitos legais. Não posso prescrever muitas drogas e, se eu fizer certas coisas com alguém que um médico possa legalmente, cometeria um crime. Da mesma forma, a maioria dos governos por aqui não permitirá que uma empresa construa uma ponte sem que um engenheiro civil licenciado aprove o projeto.

Houve propostas para licenciar programadores, mas nenhuma que eu saiba já foi a lugar algum. Provavelmente seria necessário ter um requisito legal de ter programadores licenciados para trabalhar nos projetos primeiro, e isso não acontecerá tão cedo. Existem organizações profissionais com códigos de ética comparáveis ​​aos códigos médicos ou de engenharia, mas sem nenhuma força legal, são mais como guias de códigos de ética pessoais.


0

Não estou pensando na dimensão ética, mas o relacionamento adequado com a base de clientes / usuários pode ser bastante variável, dependendo do tipo de mercado. Onde trabalho, temos um produto altamente técnico e usuários altamente técnicos, e a receita média por cliente é bastante alta. Portanto, nossos limites de negócios são um pouco embaçados: temos clientes e revendedores de valor agregado que atuam como consultores, que auxiliam no check-out de código e podem até enviar módulos para inclusão no software. Se estivéssemos vendendo uma aplicação de mercado de massa, esse modelo não faria nenhum sentido.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.