Eu trabalho como gerente de projetos do Live Typing. No ano passado, escrevemos em nosso blog corporativo que, se o prazo terminar, o principal não é surpreender e alertar o cliente. Mas quanto mais trabalhamos, mais percebemos que piores do que prazos quebrados só podem ser complexos, clientes e equipes emocionais se esgotam sob sua pressão.
As empresas que adquiriram alguns clientes regulares durante o trabalho sabem como filtrar leads suspeitos, mesmo na primeira chamada, e podem pagar por isso. Infelizmente, jovens estúdios em busca de experiência e ganhos, infelizmente, não podem prescindir desses clientes.
Antes de entrar no top dez de várias classificações do setor, a
Live Typing trabalhou com um cliente que desmotivou a equipe tanto que as pessoas começaram a deixar a empresa. Pelas razões que discutirei abaixo, concordamos novamente com o cliente. Temendo uma nova crise nas relações, desenvolvi uma tática de gerenciamento especial para manter a equipe sã e salva. Afinal, é difícil encontrar um desenvolvedor legal, e treinar e adaptar um novo funcionário é mais caro do que manter um antigo. Além disso, as especificidades da terceirização são tais que, após esse projeto, os desenvolvedores adotam o próximo, e é importante que o façam com cérebros que não foram completamente destruídos.
Sobre como eu fiz isso, leia o artigo.
Por razões óbvias, chamarei o cliente simplesmente de "cliente". Mesmo no projeto, com cooperação repetida, nós, dentro da equipe, não chamamos mais nada. Porque Sobre isso abaixo.
Antecedentes
Dois anos atrás, um projeto chegou até nós. Antes de chegar até nós, cerca de cinco equipes trabalharam nele, e ele acumulou um código legado decente.
As relações do cliente com as equipes anteriores estavam longe das do parceiro, então, com ele, ele decidiu automaticamente assumir uma posição ofensiva e se cercar de um muro de desconfiança.
Para acelerar a comunicação e o desenvolvimento, o primeiro gerente de projeto tornou o bate-papo no Slack comum para o cliente e a equipe - o aplicativo não foi desenvolvido por nós e levantou muitas questões que precisavam ser rapidamente endereçadas ao cliente. Na maioria dos casos, essa metodologia acelera a transferência de informações entre os membros da equipe, mas nosso cliente não se negou a oportunidade de fazer comentários rudes no bate-papo ou no pessoal de uma pessoa específica.
O cliente procurou personalidades, o que resultou em conflitos abertos, e seu nome foi ouvido até mesmo por aqueles que não estavam envolvidos. Como resultado, a empresa perdeu pelo menos um funcionário que não aguentava essa atitude e muitos outros deixaram o cargo após alguns meses. As razões formais para sair pareciam diferentes, mas sabemos algo.
Quando o cliente ficou sem dinheiro, terminamos. Vale a pena notar que o dinheiro foi investido, incluindo suporte ao código legado e o desenvolvimento de funcionalidades para fins de funcionalidade.
O cliente retornou mais tarde. Ele nos convenceu de que queria desenvolver o aplicativo do zero, abandonando códigos desatualizados, reduzindo a funcionalidade e se comunicando em um estilo diferente. Aceitamos, mas depois de algum tempo a história começou a se repetir.
O cliente não confiou em nossas classificações e ofertas. Ele tinha sua própria idéia de como o produto deveria funcionar. Também tínhamos um entendimento de como fazê-lo, mas o cliente não percebeu os argumentos e, em vez de um parceiro com experiência em desenvolvimento de aplicativos, ele viu em nós apenas as mãos que transformam sua lista de desejos em vida. Não sabemos os motivos pelos quais o cliente se coloca nessa posição e não especula.
A situação estava esquentando. Lembrando como os eventos se desenvolveram no passado, priorizamos uma ordem incomum para nós: primeiro, você precisa salvar a equipe e somente então fechar com sucesso o projeto e, se possível, manter a lealdade do cliente.
Táticas de proteção para clientes complexos
Agora, vamos dar uma olhada nas técnicas que nos ajudaram a alcançar nosso objetivo, nos erros que você não deve repetir e nas conclusões que você pode usar em seu trabalho.
Explicar o valor do design
Então, o projeto começou do zero. No contexto desta decisão, surgiu uma proposta para fazer MVP e pagar por nosso trabalho de acordo com o modelo de preço fixo. Isso parecia lógico, porque se não houver código de outra pessoa, não haverá riscos.
O menos o preço fixo como modelo de pagamento é que ele priva o projeto de flexibilidade: enquanto a funcionalidade está sendo implementada, com a qual as partes concordaram na tarefa técnica, o mercado pode mudar e o resultado do trabalho não resolve mais os problemas reais do usuário. É possível desenvolver MVPs a um preço fixo somente se você testou exaustivamente todas as hipóteses, projetou as especificações técnicas e escreveu a documentação detalhada. Nosso cliente apenas negligenciou o design, ou melhor, assumiu a responsabilidade.
A história com a escolha de um serviço para bate-papos é indicativa. O cliente investigou as possíveis soluções técnicas e ofereceu vários serviços: "Qual é o melhor?" Escolhemos o serviço A porque ele se adequava ao projeto em um conjunto de métodos de API e, do ponto de vista do desenvolvimento e integração, era melhor que o serviço B. Não projetamos o serviço para trabalhar com nossa infraestrutura e não verificamos nada além desses critérios formais: nem estabilidade , sem velocidade de resposta, nada - não havia orçamento. O bate-papo acabou respondendo mais lentamente do que poderia se houvesse tempo para verificar.
Não caia nas manipulações no espírito de “Se você precisar concluir uma tarefa, faça de graça! Você precisa fazê-lo bem! ”Se houver: a essência do desenvolvimento da terceirização é resolver os problemas do cliente por dinheiro do cliente.
O analista deve projetar. Ele tem o conhecimento que lhe permite entender e articular claramente o que exatamente o cliente precisa no final e construir uma arquitetura de sistema comum: quais serviços estarão no produto, se há integração com sistemas de terceiros, como as solicitações vão entre serviços, onde as informações são armazenadas, como é entregue etc. Isso é necessário, em primeiro lugar, para que o produto do cliente funcione de maneira rápida e confiável e, em segundo lugar, para aconselhar sobre o que você pode economizar e o que exatamente não vale a pena.
Torne o significado de MVP o mesmo para todos
O que o MVP significava para nós:
- concordamos com a funcionalidade básica do aplicativo e aprimoramos o ideal apenas para os recursos relacionados a ele. Outros recursos devem funcionar para que não haja desejo de fechar o aplicativo;
- oferecemos o mínimo de funcionalidade necessária para solucionar um problema comercial e nenhuma área administrativa projetada;
- adiamos a personalização para mais tarde, ou seja, usamos componentes no design que podem ser reutilizados em várias telas, recusamos elementos de layout complexos e simplificamos o design, se necessário.
Mas os clientes MVP têm interpretações diferentes. O que isso significa para o nosso:
- funcionalidade mínima para dinheiro mínimo.
No futuro, aconteceu de alguma forma que "o dinheiro mínimo" permaneceu e a posição "sabemos como fazê-lo, assim como o que dizemos" foi adicionada.
Essa posição ameaça uma parceria normal. A ameaça só pode ser removida pelo design e por uma tarefa funcional, que explica tudo o que o aplicativo deve fazer. Existem novos requisitos e sugestões não confirmados? Consulte a Lei Federal e ofereça tempo para ganhar tempo. Talvez isso seja formalismo e não sobre o foco no cliente, mas seja justo em relação à sua empresa.
Mais uma vez: o MVP é combinado com a correção quando há design. Nós não tínhamos, mas você deveria tê-lo.
Deixe os desenvolvedores discutirem com você
E nunca trabalhe com um design não comprometido do cliente, como trabalhamos.
Os desenvolvedores costumam ser vinculados: assim que a tarefa é definida, eles o fazem. Mas em projetos com um orçamento limitado, a implementação de cada tarefa potencialmente complexa deve ser posta em causa para flexibilizá-la e cumprir o prazo.
A origem dessas tarefas foi inesperadamente o design com o qual o designer do lado do cliente lidou. Nossos desenvolvedores foram informados de que, se pedirem algumas correções, eles serão enviados imediatamente, então começamos a trabalhar não com a versão estática do design, mas no editor Figma, onde esse design foi criado. Os desenvolvedores fizeram uma avaliação e começaram a trabalhar.
E então, um por um no design, começaram a aparecer elementos que não eram originalmente - isso podia ser visto no backup, que eu fiz apenas por precaução. Porém, antes de iniciar o desenvolvimento, é impossível verificar se uma determinada peça de design foi alterada - pelo menos porque o desenvolvedor executa tarefas em uma ordem conveniente.
Identificar inconsistências ajudou a mesma liberdade de expressão. O desenvolvedor pode vir até mim e apelar não apenas dos elementos que não podem ser criados rapidamente, mas também dos elementos do design do cliente - isso é compreensível, porque o próprio designer os introduziu secretamente lá, mas não em nossa cópia. Esses elementos não foram incluídos na avaliação, o que significa que não devemos lidar com eles às nossas próprias custas.
No mundo do desenvolvimento saudável, o preço fixo não permite aumentar a quantidade de trabalho e alterar as condições em movimento.
Mantenha o cliente longe da equipe
Da última vez que conectamos os desenvolvedores e o cliente diretamente - há equipes nas quais acredita-se que o gerente deve primeiro monitorar os termos e o orçamento, e não servir como transmissor dos requisitos do cliente.
Essa é uma ótima metodologia com suas vantagens: a reação de cada lado é mais rápida, a equipe entende melhor a tarefa do negócio, sua autoridade cresce e o gerente não morre como transmissor. Mas, sabendo que o cliente pode se tornar pessoal, eu o isolei da equipe. Somente o cliente, gerente de contas e gerente de projetos, ou seja, eu, permaneceu no bate-papo.
O que isso nos deu? Moderava a comunicação e não permitia que as relações pessoais envenenassem a rotina de trabalho. Nos momentos em que o cliente criticava a equipe, respondi que agiríamos e puniríamos o funcionário. As observações mostram que, para tranquilizar alguns clientes, basta sacrificar alguém da equipe mesmo por diversão, para que o funcionário continue trabalhando com calma e nem saiba que foi punido.
Se você suspeitar que o cliente está inquieto, não leve a equipe com ele pelo menos por um tempo, até que você esteja convencido do contrário.
Reformule o feedback do cliente para a equipe
Em uma atmosfera de constante desconfiança e crítica, a equipe não consegue mais processar o feedback na forma em que chega, e o cliente começa a pensar que a equipe começa a trabalhar apenas com más intenções - e as encarna.
O que fazer com esse gerente? A edição cosmética não faria mal: eu removi a avaliação da personalidade do feedback, deixando apenas a redação do erro sem perda de significado. E como você não recebe elogios do cliente, não esqueci de dar à equipe o meu próprio feedback - pelas tarefas que não suscitavam perguntas, o que significa que elas foram bem executadas do ponto de vista do cliente.
Foi:
“O aplicativo não funciona com pagamento. Que mãos você fez?Tornou-se:
“Pessoal, o aplicativo tem algo a pagar, o cliente pede para descobrir, aqui estão as capturas de tela. E com as animações que ficaram para trás há uma semana, estava tudo bem. ”Não se apresse para obter erros
A inserção de erros no gerenciador de tarefas assim que eles foram recebidos do cliente é por inexperiência. Armado com um olhar crítico, o gerente ajudará a economizar horas de desenvolvedores e um testador. Apenas conversando com o cliente ou pedindo para reproduzir as ações que levaram ao erro e gravar o vídeo, você pode entender que o bug não é uma prioridade ou apareceu porque o cliente estava fazendo algo errado - e agora você não precisa mais editá-lo. Portanto, peneirei um quarto dos bugs recebidos e outra parte estava relacionada ao serviço de suporte de serviço integrado - havia SDKs de terceiros suficientes no projeto.
Não mencione o nome do cliente
Talvez o insight mais importante. De acordo com a antiga memória de uma parte da equipe, a expressão do nome de um cliente provocou uma atitude tendenciosa a qualquer comentário da parte dele, por mais adequado que fosse. E cheguei a ligar para o cliente apenas o cliente, o que reduziu o negativo. Parece que todo mundo entende de quem está falando, mas acredite: essa nuance melhorou a ecologia do projeto.
Conclusão
Para maior clareza, decidi reduzir todas as opções acima a uma tabela com o princípio "Como não fazer e como fazê-lo".
Porém, nosso conselho será útil para você, no mínimo, se a pessoa responsável por trabalhar com clientes entrantes em sua empresa ou o gerente de conta revelar falhas do cliente na fase de negociação.
Aqui estão alguns pontos importantes que agora estamos prestando atenção:
- O que o cliente diz sobre o contratante anterior, se ele era. Se ele fala negativamente dele, é possível que ele não perceba outra opinião além da sua e imponha suas decisões.
- O cliente tem experiência em TI. Para um cliente com experiência, o processo de desenvolvimento levanta menos questões.
- Se ele pechincha por cada centavo ou não. Quanto maior o desejo do cliente de pagar menos, mais voluntariamente e teimosamente ele argumenta.
Espero que este artigo seja útil para alguém. E se você já estava no meu lugar, conte-nos como resolveu clientes tão difíceis.