Quando alguém solicita um projeto, devemos assumir que é muito importante e que se preocupa profundamente com o produto no qual trabalhará. Portanto, é seguro presumir que um cliente é forçado a criar uma grande expectativa sobre o produto final e, portanto, pode ficar emocionado quando se trata da entrega.

Ao longo do projeto, um cliente pode se sentir muito animado com uma performance entregue e amá-lo, e no dia seguinte ele pode descobrir que algo está errado e o carinho vai desaparecer. Na maioria das vezes, é apenas uma questão de falha na comunicação com o cliente.

Embora não haja receitas para o sucesso quando se trata de desenvolvimento de software remoto , Acho que há algumas coisas que Deveria ser evitado manter um relacionamento produtivo e saudável com clientes que confiam em suas mãos.

Nenhuma falha na comunicação básica com os clientes

Imagine comunicar-se com os clientes da mesma forma que se comunicaria diariamente com colegas de trabalho, amigos ou qualquer outra pessoa a quem você estenda sua cortesia.

Se um velho amigo visitar sua casa e você concordar em saborear uma iguaria local 'em sua casa' ao meio-dia, algumas semanas depois, você simplesmente aparecerá lá? Você poderia manter contato enquanto isso, ligar para confirmar alguns dias antes? Ou talvez você pensasse que ele está muito ocupado e não gostaria de incomodá-lo sem um bom motivo? Você espera que eu o notifique quando eles chegarem?

É improvável que você continue conversando todos os dias, a menos que tenha uma tonelada de informações, mas manterá algum tipo de comunicação, por cortesia e praticidade - você não quer que a outra pessoa pense que você se esqueceu dela, mas você definitivamente não quero dirigir pela metade do caminho pela cidade sem um bom motivo.

Em algum momento, você provavelmente já passou por situações semelhantes em sua comunicação profissional, mesmo com parceiros e colegas de trabalho de longa data. Alguns projetos são executados com o mínimo de comunicação, como dizer “o de costume, ao meio-dia, nos vemos aí” para confirmar um almoço leve. Mesmo se algo acontecer, a outra parte certamente o informará e concordará em reagendar.

No entanto, as coisas não são tão simples ou lineares no mundo do desenvolvimento de software.

Se você começar a trabalhar em um projeto, principalmente quando está lidando com um novo cliente, se ele nunca ouvir de você, vai começar a ter dúvidas sobre o seu trabalho e compromisso. Mesmo que você apareça com um produto perfeito depois de algumas semanas, os clientes podem ter uma percepção inferior à ideal de você.

Mesmo que você se sinta desconfortável às vezes, não custa nada conversar com o cliente, mesmo que você não tenha nada fora do comum para relatar. Você tem alguma dúvida sobre um pequeno ponto na história de um usuário? Se você acha que é importante, diga a ele. Você está um pouco atrasado e não tem certeza se conseguirá cumprir a data estimada que combinou? Ligue para o cliente o mais rápido possível! É melhor você ouvir imediatamente.

Você não tem dúvidas e o projeto se encaixa perfeitamente, mas o cliente não fala muito? Por que não simplesmente enviar um e-mail descrevendo seu progresso em intervalos de alguns dias? Não causará nenhum dano porque os e-mails não incomodarão ninguém, eles também documentarão seu progresso e manterão comunicação regular com o cliente.

A comunicação deficiente com o cliente promove expectativas irrealistas

No começo eu mencionei que o cliente com certeza vai ter grandes expectativas em relação ao projeto, certo? Você os terá. ponto.

O cliente já espera muito do produto. Se não for da maneira que eles imaginaram, os clientes ficarão inevitavelmente frustrados. Então, por que alguém promete mais do que pode cumprir, criando expectativas ainda mais irrealistas?

Aqui está um rápido paralelo: Você comprou um tablet online e eles nos prometeram uma entrega de 10 dias. No oitavo dia, a loja informa que há um problema e está atrasando a entrega por uma semana. Para compensar o transtorno, as promessas do varejista dão a você um crédito de US $ 75 na loja.

Você provavelmente não precisará daquele tablet nos próximos dias, então você acha que é um bom negócio! Agora você pode curtir o tablet, além de usar o crédito da loja para comprar algo bacana para seus filhos. Mas a loja liga no dia seguinte, dizendo que tudo foi consertado durante a noite.

Você receberá o comprimido no dia seguinte. Sem extras, sem crédito na loja. Agora você está frustrado!

'Que? Você só me disse ontem que eu faria um negócio melhor! Não é justo! Já falei para as crianças ... '

Retroceda alguns dias e tudo o que você esperava era o tablet de qualquer maneira. Se ninguém lhe tivesse prometido um negócio melhor, você ficaria satisfeito com seu tablet quando ele chegasse no dia seguinte. Mas agora, você sente que está perdendo algo por um bom motivo, além da decisão da loja de informá-lo.

Como os desenvolvedores, especialmente freelancers, podem evitar situações semelhantes em sua comunicação com os clientes?

Por não pirar e dizer tudo o que vem à sua mente em primeiro lugar. As sugestões não são proibidas; na verdade, eles são muito bem-vindos se você achar que um determinado recurso solicitado não é uma opção muito boa para resolver o problema em questão. Mas a chave é: 'Pense primeiro'.

• Ouça o cliente.

• Analise seu problema.

• Analise a solução proposta.

• Certifique-se de que está dentro do orçamento / cronograma.

• Por fim, vá em frente e envie sua sugestão.

É por isso que as habilidades de comunicação com o cliente podem ser complicadas, já que falhar em apenas uma das quatro primeiras etapas significa que você pode acabar perdendo seu tempo e, pior, o tempo de seu cliente.

Não presuma que você sabe o que o cliente precisa

Parafraseando Mary Schmich Senhoras e senhores da turma de 17: Ouça o cliente. Se eu pudesse te dar apenas uma dica para o futuro, ouvir o cliente seria essa.

Se você foi chamado para um projeto é porque alguém precisa de algo. E quem saberia melhor sobre essa necessidade do que seu cliente? Pode parecer óbvio, mas às vezes, no mundo real, as pessoas esquecem.

Deixe-me lhe dar um exemplo. Um varejista solicita um 'sistema de software' para seu negócio. Assim que você vê, chega à conclusão que o que eles querem é registrar todos os produtos disponíveis, registrar cada compra realizada, gerar recibos para os clientes e relatar o que foi vendido periodicamente e quais itens estão acabando. valores.

Por isso, no seu primeiro encontro, você quer mostrar que é eficiente e apresentar o que você preparou, as funcionalidades propostas, um design básico para combinar com a identidade visual da loja e tudo. Mas então o cliente perplexo diz que o que ele realmente precisa é de um algoritmo para calcular a melhor forma de exibir os produtos nas prateleiras, com o objetivo de aumentar a receita de marcas e produtos específicos.

O erro aqui foi simplesmente não identificar qual problema você deveria resolver. Claro que neste caso, como era muito cedo no projeto, demoraria muito para acertar, mas às vezes esse tipo de erro acontece mais tarde. Mesmo que não seja tão drástico como o exemplo acima, pode prejudicar o projeto e / ou seu relacionamento com o cliente.

Minha sugestão é a seguinte: converse com seus futuros usuários, muito se possível, e consulte várias partes interessadas no projeto. São eles que têm uma boa visão geral da situação e sabem do que precisam. Tente descobrir o que eles fazem atualmente, a cada passo do caminho, e explique como o software seria útil. Gosto de dizer que, quando tento entender o que um cliente deseja, meu objetivo é quase conseguir fazer o trabalho sozinho. Se você chegar perto desse ponto, terá realmente descoberto quais são as necessidades deles.

Não está entendido o que o cliente está pedindo

Não é incomum receber algum tipo de documentação sobre o problema em questão. Às vezes, é apenas uma descrição de alto nível, enquanto outras vezes é um documento detalhado com casos de uso e regras de negócios. Em qualquer caso, não importa quão claros sejam os registros, a única coisa que não pode ser feita é simplesmente assumir que tudo o que está escrito ali é a verdade absoluta.

Que???

Exatamente. Em primeiro lugar, algo pode significar uma coisa para alguém, em um determinado contexto, e uma coisa completamente diferente para pessoas que não pertencem a essa realidade. E se há algo que você e o cliente não têm em comum, é o contexto!

Em segundo lugar, nem todos são escritores muito qualificados; Eles tentam dizer A, mas acabam descrevendo B.

Então, depois de ler tudo o que eles enviaram, como você pode ter certeza de que o que leu é realmente o que eles queriam dizer? Bem, você pode digerir tudo, tomar notas, analisar tudo e ... convocar uma reunião . (Viu? É tudo uma questão de comunicação!) Na reunião, você falará sobre o problema e descreverá o que entendeu com suas próprias palavras. Nesse estágio, você provavelmente será capaz de identificar quaisquer mal-entendidos.

“Ah, mas no meu caso não recebi nenhum documento. Acabei de me sentar com o cliente e ele me explicou tudo enquanto eu fazia algumas anotações. '

Bem, ainda não há garantia de que você entendeu o que eles significam e minha sugestão ainda se mantém: reserve um tempo com suas anotações, pense em todo o problema, organize tudo, de preferência em algum tipo de cronograma de eventos, e depois ligue / encontre novamente com o cliente para apresentar o que você entendeu. Pode parecer repetitivo para você, mas às vezes até o cliente não tem uma visão completa de todos os processos envolvidos para realizar uma tarefa específica e você verá o quão complexo o software terá que ser.

No final, você deve ter certeza de que não há ambigüidade ou mal-entendido.

Por que você não deve entregar tudo o que o cliente pede sem pensar

Ok, agora que você sabe que precisa ouvir o cliente e confirmar o que entendeu, pode ir em frente e fazer o que ele pedir de você, certo?

Incorreta!

Agora é a hora em que você pode finalmente usar toda a experiência que tem e se perguntar: É o que o cliente pediu para você resolver? O que eles perguntaram a você é realmente o que eles precisam?

Você ficaria surpreso com quantas vezes a resposta é 'não'.

Antes de apenas entregar o que o cliente solicitou, precisamos analisar a questão e se você não concorda com o que o empregador propôs, é seu trabalho e responsabilidade profissional deixar isso claro. Obviamente, você deve explicar por que acha que a proposta deles não é boa e qual será sua abordagem alternativa para solucionar essas deficiências. Mais uma vez, a comunicação é a chave.

Se você e o cliente forem razoáveis, prossiga com sua solução ou faça uma sessão de brainstorming para encontrar uma melhor (no caso de sua ideia não ser aceitável para o cliente por algum motivo).

Protótipo - não escreva uma grande quantidade de documentação

Já falei que geralmente você e seu cliente não têm a mesma perspectiva, certo? Portanto, da mesma forma que afeta sua compreensão da documentação, afetará a compreensão do que você entregará por escrito. É uma questão de contexto.

Portanto, concordo que de alguma forma (em um nível superior ou inferior), temos que documentar o que estamos prestes a desenvolver. Mas entregar várias páginas de texto sem recursos visuais não fará muito bem. O cliente ficará entediado de ler, parará de prestar atenção em você e provavelmente não será capaz de entender o que você quer dizer com essas regras de negócios complexas, ou interpretará algo completamente diferente do que imaginou.

Lembre-se que esses mal-entendidos podem ser ainda piores se o cliente não tiver treinamento técnico.

Todos esses fatores podem resultar no mesmo resultado problemático - os clientes reclamarão quando você entregar o produto porque provavelmente não é o que eles tinham em mente.

Isto é o que sugiro: Sempre faça um protótipo, mesmo que seja apenas um esboço para desenhar o seu plano. E qualquer definição que você tenha que fazer, comece a partir daí. Faça referências e tente manter as coisas simples.

Pare de perder tempo tentando convencer o cliente de que você está certo

Posso quase ter certeza de que todo desenvolvedor já passou pela seguinte situação: No início do projeto, o cliente diz “Preciso que a cor de fundo do software seja amarela. Já foi acordado pelo conselho ” . Então, quando o software é entregue, eles dizem: “Ah, mas a cor de fundo não pode ser amarela. Eu disse que tinha que ser verde! ' Agora, como você deve lidar com isso?

Na verdade, não adianta, em qualquer caso, insistir que você estava certo e eles errados. De qualquer forma, isso apenas dificultará para você e para o cliente.

É sempre bom ter um bom registro de comunicação com o cliente, apenas para garantir que você esteja na mesma página e deixe um rastro por escrito. Na maioria das vezes, se for algo simples, você pode enviar um e-mail ao cliente dizendo: 'Como combinamos naquela reunião, o plano de fundo do sistema será amarelo.' E se, no futuro, o cliente alterar sua nota de que pode argumentar que o fez por causa da reunião mencionada no e-mail, mas se essa modificação realmente precisar ser feita, você pode executá-la por mais x horas ( e, às vezes, x dólares extras).

Mas se não houver nada que prove que você estava certo, então você provavelmente terá que tomar uma decisão (além de aprender uma lição): a mudança é tão grande que exigirá uma mudança na arquitetura atual ou afetará outros recursos? Caso contrário, provavelmente é melhor ir em frente, fazer e ter o cliente ao seu lado (mas com os olhos bem abertos para que não aconteça novamente). Se o fizer, uma conversa com o cliente será a melhor solução; não aquele que se concentra em 'Como ele estava certo' , mas em 'Como podemos resolver o problema atual' .

Em qualquer caso, a melhor maneira de evitar ter que fazer grandes modificações é fornecer novos recursos curtos em curtos períodos de tempo. Portanto, se algo precisa ser mudado, provavelmente não será uma grande transformação do que já existe.

Aprenda quando se comprometer com prazos de entrega

Por último, mas não menos importante, um dos maiores erros que você pode cometer é dar ao seu cliente um prazo para terminar o projeto. E eles vão implorar que você cometa esse erro!

Claro, como cliente, você quer saber quando poderá usar todos aqueles recursos interessantes que você tem discutido nas últimas semanas (meses?). Mas como um projeto não é um produto definido, muita coisa pode acontecer desde o início do desenvolvimento até que o software esteja pronto para uso.

Em primeiro lugar, você não pode prever o imprevisível. É muito provável que você tenha que lidar com algo que não esperava. Pode ser uma licença que o cliente prometeu não ter sido comprada a tempo, ou algum outro software interno que você precisa usar, mas não foi lançado quando deveria, ou o ambiente era diferente do que foi originalmente acordado, ou o o cliente mudou de ideia sobre alguns (poucos) recursos e teve que refazer algumas coisas.

Nada disso é realmente culpa do desenvolvedor e pode afetar profundamente o cronograma do projeto. Mas se você, querendo agradar o cliente, prometeu que entregaria tudo em uma determinada data e você acabar não podendo por qualquer motivo, uma coisa que posso garantir é que o cliente ficará pelo menos um pouco frustrado. Se você é um freelancer, precisa gerenciar seu tempo de forma eficiente, conforme explicado o artigo do ApeeScape Dev Blog . Não se esqueça de que a gestão do relacionamento com o cliente também é sua função.

Então, faça um favor a si mesmo e a quem está dependente do projeto, e pelo menos dê uma estimativa de quanto tempo vai demorar para desenvolver tudo, mas sempre deixe claro que é apenas uma estimativa e não um prazo.

Além disso, sugiro fortemente (especialmente se você já fez uma estimativa) que sempre diga ao cliente quando algo vai demorar mais do que o esperado, para que possam agir para ajudá-lo.