Projetar tecnologias para a implementação de sistemas de cobrança para clientes corporativos (parte 2)

Trabalhamos com riscos em nível global


No último artigo sobre casos de design, falamos sobre problemas. Em um exemplo, uma cascata teve que expandir os limites do projeto, alterar o BPI e reconciliar orçamentos. No segundo projeto com uma metodologia flexível, o cliente não se beneficiou. No terceiro caso, a abordagem híbrida nos permitiu concluir o projeto com sucesso e dentro do prazo, apenas porque a equipe do projeto por parte do cliente estava bem motivada pelo resultado e, reconhecendo os recursos limitados, introduzindo novas configurações, removeu tarefas menos prioritárias dos sprints. Vamos nos referir ao primeiro artigo, portanto, se você não o leu, faz sentido olhar para ele pelo menos na diagonal - aqui está o link .

É fácil descrever retroativamente esses casos e designá-los como bem-sucedidos ou não. Mas, no processo de trabalhar nelas, tudo parece mais complicado e é impossível indicar antecipadamente um resultado negativo. Além disso, as perdas financeiras e de reputação em projetos corporativos podem ser muito, muito grandes.

imagem

Antes de tudo, avaliamos os riscos do ponto de vista de nós, como organização executora de um projeto de automação:

  1. Determinamos os principais riscos do novo projeto e sua criticidade.
  2. Comparamos as metas do projeto anunciadas pelo cliente com o fato de podermos considerá-las necessidades reais com base em nossa experiência no projeto.
  3. Determinamos as prioridades dos prazos, orçamentos, funcionalidade declarada.
  4. Então devemos tomar decisões fundamentais sobre os cenários de reação aos riscos que se desenvolveram.
  5. Consertamos uma quantidade aceitável de perdas para nós mesmos se tudo desse muito mal.
  6. Estimamos quanto o volume de riscos está aumentando em todo o portfólio de projetos que a Forward está conduzindo atualmente, se adotarmos um novo projeto.
  7. E, no final, decidimos quanta perda ou dano à reputação nos forçará a iniciar um processo legal, quanto estamos dispostos a gastar em suporte jurídico.

É importante ressaltar que aqui avaliamos os riscos para nós, como uma organização como um todo - aquilo que pode prejudicar nossa integridade, como uma unidade estrutural e levar ao colapso da organização. Uma avaliação de risco mais detalhada de um projeto específico é realizada dentro da estrutura do próprio projeto e é registrada na documentação do projeto de acordo com a metodologia de gerenciamento de projeto escolhida.

Agora, sobre os riscos que estão além do nosso controle e os principais aspectos sem os quais seria impossível concluir o trabalho nos projetos descritos sem perdas de reputação e financeiras.

Não depende de nós


Aqui está uma lista de riscos que afetamos pouco ou que não podem afetar, mas devemos considerar:

  1. Perda da estabilidade financeira
    O Cliente não pode pagar mais e congela / encerra o projeto.
  2. /
    , . , . .

    : . — . , .
  3. / ()
    , , , , - .

    : MVNO-, , . , . , - , , , .

  4. , «», / .

    : — , , . , - . , , , .
  5. Alterações regulatórias
    Por exemplo, a lei da primavera. Há coisas que você não sabe com antecedência quando começa a trabalhar. Mas essas mudanças podem simplesmente matar a economia do projeto, forçando o cliente a abandonar o projeto.

Esses riscos são facilmente combinados em projetos reais. Tínhamos que, em um projeto, o regulador bloqueou os fluxos financeiros e o cliente foi forçado a congelar parte de nossas atividades. Em seguida, a gestão do cliente mudou e o paradigma de gerenciamento da empresa foi revisado, respectivamente, necessário para a implementação do subsistema diferente do planejado originalmente.

A palha deve ser colocada com antecedência


E com palha queremos dizer contratos e acordos corretamente redigidos.

Se, de acordo com o contrato, for apenas necessário, não teremos direitos e o cliente não será responsável por nada - o preço desse contrato é inútil. Não importa quão boas são as relações pessoais com os representantes dos clientes. Mesmo em um projeto curto, podem ocorrer mudanças que mudarão fundamentalmente o mapa de forças no projeto. O proprietário pode mudar, um cliente funcional chave deixará a organização, a empresa começará dificuldades financeiras.

O acordo deve especificar explicitamente as possibilidades de alterar os limites do projeto por iniciativa de cada uma das partes e sob quais condições as alterações podem ser iniciadas. Não é possível economizar com advogados ao elaborar e concluir um contrato. Além disso, é necessário que o advogado seja bem versado em nossas especificidades de atividade ou dedique um tempo especial ao estudo da questão para definir corretamente as condições de trabalho.

Existe alguma comunicação? E se eu encontrar?


As negociações são a pedra angular. A base de obrigações e responsabilidades fixas, formou expectativas e um entendimento comum do que está acontecendo.

Sem um bom negociador, o funil de vendas é bastante reduzido, porque simplesmente não funciona para convencer o cliente a trabalhar conosco. No projeto em que os riscos funcionaram, o negociador deverá justificar alterações no orçamento, concordar com novos termos ou dividir a funcionalidade em várias fases. Na pior das hipóteses, será necessário concluir o trabalho com o cliente em uma nota neutra, minimizando as perdas para si.

Por exemplo, no segundo caso do último artigo, falamos sobre o fato de o cliente não ter obtido o resultado final, em algum momento a pontuação para continuar o trabalho e a não formação de um novo sprint. Se entendermos que o projeto congelou, é necessário resumir o trabalho realizado, apresentar essas informações ao proprietário e tentar reviver o projeto. Essa também é uma tarefa para o negociador.

As tarefas do negociador também incluem ajudar os clientes funcionais a se comunicarem com a equipe de projeto do cliente, caso não possuam competências.
Nosso negociador, dependendo do tamanho do projeto, seus recursos, estágio do processo de negociação, pode ser vendas, gerente de projetos (RP), gerente de contas, diretor.

Vendas conduz palestras e apresentações iniciais. Em grandes projetos, após negociações iniciais bem-sucedidas, as vendas transferem informações para a equipe do projeto e não estão mais envolvidas nas negociações. Em pequenos projetos, as vendas podem assumir parte da comunicação com o cliente, cumprindo parcialmente as funções de um vendedor e gerente de contas.

Os RPs são freqüentemente percebidos como um gerente de natureza puramente técnica, que não pode discutir suas decisões sobre a lógica de negócios com os clientes. Portanto, é necessário conectar artilharia pesada.

Um gerente de contas é uma posição alta e a conta deve ser incluída nos mesmos círculos do cliente. Então temos uma conversa aberta e substantiva. Na maioria dos projetos, é o gerente de contas que é o principal negociador e geralmente é responsável pelo gerenciamento de riscos no projeto. Se necessário, a conta atrai diretores.

Se, no estágio inicial da discussão dos diretores do projeto, estiveram envolvidos para discutir questões críticas, os gerentes de nível inferior têm medo de violar os acordos e escalar situações problemáticas para não assumir responsabilidade.

O algoritmo para analisar o risco acionado é aproximadamente o seguinte:

  • Analisamos o problema, suas causas.
  • Desenvolvemos opções para o modelo ganha-ganha, organizamos-as na forma de um roteiro.
  • Sentamo-nos à mesa da negociação e oferecemos abertamente opções ao cliente.

?


imagem

Existe um contrato e negociadores corretos por parte do cliente e do contratado? Vendedores e clientes funcionais concordaram com o desejado, estimou a quantidade de trabalho? Até os tomadores de decisão concordaram em tudo? Ainda é muito cedo para relaxar.

À frente do projeto em si, há meses e, às vezes, anos de trabalho com prazos, ativação do trabalho nas etapas do projeto, comissionamento da operação funcional para a experimental e industrial, treinamento do usuário.

Para que o trabalho seja eficaz, são necessários motivação e interesse adequados das equipes do cliente e contratado. E é bom para nós, como artistas, saber qual a motivação da equipe do cliente. E às vezes até faz sentido focar isso nos estágios iniciais do projeto, a fim de entender melhor o equilíbrio de poder e interesses. Você pode oferecer ao tomador de decisão do cliente uma motivação especial para sua equipe.

Globalmente, existem duas abordagens:

  1. Monetário

    Quando o projeto é concluído no prazo, com manutenção da margem, a equipe recebe de 5 a 7% do custo do trabalho.

    Na prática, o circuito raramente funciona. A maioria dos projetos não é concluída dentro do prazo, porque no processo de implementação há muitas mudanças. Por esse motivo, os participantes ficam desmotivados - trabalharam por quase 6 meses à noite para cumprir os prazos, e agora a configuração mudou, o plano básico do projeto foi reescrito, o calendário foi atualizado e o período total aumentou em três meses.

    A lacuna no interesse de artistas e negócios. Os contratados aguardam incentivos no período especificado e contra alterações que afetam o orçamento, os custos de mão-de-obra e a mudança de tempo. E os negócios não precisam mais da declaração original do problema. Os negócios perceberam que agora a tendência é diferente.

    , , .


  2. . — , , . . , , .

    — . . .

    O terceiro elemento é inicialmente ganhos decentes. Sem isso, você não pode recrutar uma equipe qualificada para um projeto. Sem isso, o especialista não pensará na qualidade do código ou na correção do processo de negócios que está sendo desenvolvido, mas no fato de receber pouco dinheiro.

No terceiro caso, com uma metodologia híbrida, tínhamos prazos apertados para o lançamento do MVNO. A equipe do cliente estava altamente motivada da mesma maneira que nós - um lançamento bem-sucedido. Não houve jogos secretos, competição entre unidades e latência. Houve uma interação ativa, o desejo de concordar em obter um resultado. E, como resultado, o sucesso é o lançamento oportuno do MVNO.

Conclusão


A automação comercial é um risco maior para o cliente do que para nós - artistas. Mas, antes de tudo, depende de nós como a situação se desenvolverá, em caso de problemas no projeto. Devemos ser capazes, sem danos fatais para o cliente e para nós mesmos, para trazer o projeto para o lançamento e não deixar o cliente à mercê do destino.

Após cada projeto, realizamos uma retrospectiva. Recordamos o que tínhamos na entrada do projeto em termos de trabalho, avaliação, custo e comparação com o que aconteceu no final. Analisamos os desvios e os riscos envolvidos: onde cometemos um erro na avaliação, onde o próprio cliente mudou a tarefa, onde o problema não dependia de nós. O objetivo retrospectivo é aumentar a precisão das estimativas de insumos trabalhistas em projetos futuros semelhantes.

Resultados Retrospectivos - Material de Treinamento. Nossos funcionários veem em que locais a falta de trabalho do analista e as deficiências da TK resultam em custos desnecessários de mão-de-obra. Também criamos um repositório das melhores soluções. E quando no novo projeto vemos que as tarefas são semelhantes, recorremos ao repositório - reutilizamos e não o inventamos do zero - reduzindo assim os custos do cliente.

Para nós mesmos, derivamos os seguintes axiomas:

  1. Documente todas as decisões e arranjos.
  2. Abordar as negociações e a formação de expectativas como um processo. Concorde propositadamente, não deixe cair tudo e não entre em silêncio. Receba continuamente feedback do cliente.
  3. Entenda por si mesmo a importância de motivar nossa equipe no projeto e explique ao tomador de decisão do cliente a importância de criar um sistema de motivação para o resultado da equipe do cliente.

Compartilhe suas experiências nos comentários. O que causa mais problemas nos projetos? Quais riscos foram desencadeados em seus projetos e como você lidou com as consequências?

All Articles