✒️ 👨‍👨‍👧 👸🏼 Projetar tecnologias para a implementação de sistemas de cobrança para clientes corporativos (parte 1) 🍉 🤟🏼 🧑🏽‍🤝‍🧑🏼

Sim, tudo foi escrito 100 vezes sobre gerenciamento de projetos

É absolutamente verdade que, a menos que os preguiçosos tenham escrito sobre gerenciamento de projetos usando diferentes metodologias. Portanto, não discutiremos situações gerais e as delícias de diferentes metodologias. Mas falaremos sobre vários casos em que os riscos funcionaram, apesar do uso de algumas metodologias de gerenciamento de projetos, e como saímos da situação problemática.

Dificuldades típicas

Primeiro, o principal e o mais interessante - sobre os problemas do ponto de vista do contratante-executor do projeto de automação. Todas as metodologias devem ajudar a se livrar dos problemas antes mesmo que eles surjam. Mas na vida isso não acontece.

imagem

Aqui estão as dificuldades típicas que encontramos com mais frequência nos projetos:

.
, , - . , . , , , , .

, , , Forward, - - .
CRM- .
CRM , , . , CRM, .

, , , , . CRM . , CRM - , : « / ?».
«» open-source .

- IT-, , . : “ open-source, ”, — , . - « , !»

. , - , , . open-source , - . , 1 .
Expectativas por tempo.
Anteriormente, a escolha dos sistemas de informação para cobrança era realizada pelo serviço de TI da empresa. Agora, cada vez mais, a escolha é feita pelas unidades responsáveis pelas vendas e marketing. A falta de formação técnica, a expansão dos serviços em nuvem e o crescimento da informatização geral da vida criam a ilusão de simplicidade. Ninguém pensa que, para o atual trabalho confortável de graça para usuários comuns, os recursos do Gmail de uma grande organização são gastos há muitos anos.

Portanto, ouvimos constantemente que as expectativas para o momento da implementação do faturamento são de 3 a 4 meses. É raro que um cliente calcule a quantidade de trabalho em seis meses ou um ano.

Se eu fosse compilar os subsistemas TOP com os quais vários problemas surgem em projetos complexos, eles seriam:

CRM
Balcão de atendimento,
Contabilidade / inventário técnico.

Agora vamos para três casos pequenos e um pouco exagerados. Todas as coincidências com pessoas reais são consideradas um acidente. Nem um único ornitorrinco foi ferido na produção do filme.

Quando a cachoeira reverte

Era uma vez um provedor de Internet, e não um simples, mas composto por muitas entidades legais que prestavam serviços em diferentes cidades. Em cada cidade, uma entidade legal tinha seu próprio histórico de cobrança, suporte, liderança local e muito mais do que uma empresa precisava
.
Por isso, eles decidiram na principal entidade legal do provedor combinar tudo em um sistema, considerar dinheiro e tráfego em um só lugar, e não deixá-los separar sistemas históricos. Para acelerar tudo, a glavurlitso lança uma licitação e seleciona um fornecedor de automação.
Estudamos a documentação do concurso. Vemos que cumprimos os requisitos, participamos da licitação e somos vencedores felizes.

Começam os problemas

E então a diversão começa. Acontece que o diretor principal deseja contratar imediatamente o projeto para toda a entidade legal, para fixar os termos e o orçamento total com força. Teares clássicos da cachoeira da água clara.

Comunicamos com a equipe responsável pela licitação, prescrevemos o BPI (plano básico de execução) do projeto, estudamos as informações detalhadas fornecidas e registramos todos os requisitos documentados. Um monte de papéis assinados, entramos no projeto.

E somos confrontados com uma realidade brutal na forma de uma incompatibilidade entre a documentação fornecida anteriormente e a situação real nas cidades onde o fornecedor está presente. Temos os riscos trabalhados:

Esticando os termos de implementação.
O aumento da mão-de-obra do projeto.
Um grau incompreensível de responsabilidade dos organizadores de concursos em uma situação em que eles não gerenciam sistemas históricos no terreno.
Falta de interesse em mudar para um único faturamento em entidades legais locais.

Reiniciar

A diferença óbvia entre os requisitos formais e a situação real nas cidades onde o fornecedor está presente nos obriga a recontar os termos e o orçamento. Forneça essas informações ao cliente. Ao mesmo tempo, incluímos custos adicionais de mão-de-obra para o estudo de sistemas históricos no orçamento.

Temos que conduzir muitas negociações com representantes da controladora. Estamos negociando. A empresa-mãe realmente deseja um único faturamento, portanto, existe uma assinatura amigável de um contrato adicional para cada cidade.
O resultado geral do projeto é positivo. As dificuldades na entrada do projeto foram resolvidas, a transição para um novo faturamento único para o grupo de empresas passou sem incidentes.

Seguir a metodologia clássica não ajudou a identificar as deficiências da declaração de requisitos técnicos e exigiu uma revisão completa de todos os acordos com o cliente e a reescrita de toda a documentação do projeto.

Puxe a videira

Um cliente veio até nós e queria lançar seu operador virtual. Calculamos o projeto de lançamento do MVNO de vários graus de independência do MNO. O cliente considerou o projeto uma diversificação dos negócios e não possuía experiência suficiente em telecomunicações. O orçamento do projeto foi planejado para ser realizado com base nos recursos liberados do negócio principal. Ao mesmo tempo, o proprietário queria trabalhar exclusivamente no Agile, considerando essa metodologia o mais progressiva possível e adequada para iniciar um novo negócio.

Decidiu-se dividir as tarefas de lançar o operador em pequenos quanta de trabalho e trabalhar em sprints, atraindo recursos disponíveis para cada sprint suficientes para o desenvolvimento do orçamento. A ativação deveria basear-se nos resultados do sprint.

Saiu um resultado do qual não teremos orgulho. Os problemas inicialmente previsíveis mostraram em toda a sua glória:

Instabilidade de recebimento de fundos para o trabalho.
O intervalo de tempo entre a aparência do orçamento e a alocação de especialistas para o desenvolvimento do orçamento.
A tentação do proprietário de gastar os fundos acumulados para o projeto, em vez de esperar o final do sprint e o pagamento do ato. Como resultado, o intervalo de tempo entre o final do sprint, a assinatura do ato e o pagamento.

Com o tempo, o interesse do proprietário em lançar um operador virtual diminuiu e, em algum momento, a implementação do trabalho de sprint foi adiada por um período incompreensível e depois completamente cancelada.

A saída do projeto, portanto, também é o resultado, embora não seja positivo.

Sem motivação suficiente do cliente para alcançar o resultado, uma metodologia flexível pode minimizar apenas nossos custos de mão de obra não ativados e não pagos. Porém, trabalhar nesse modo reduz e distrai muito os recursos da implementação de projetos mais econômicos. Esta é uma experiência negativa e não lançaremos projetos com condições semelhantes.

Ágil com tempo, orçamento e limitações de funcionalidade - WTF ?!

Sim, há tal coisa. O cliente pode querer trabalhar no Agile, mas ao mesmo tempo fixar os prazos, orçamento e funcionalidade. Para nós, isso causa dissonância.

Para nós, trabalhar em um Agile puro com um cliente implica fornecer uma equipe, e o cliente participa significativamente do esforço de gerenciar o projeto. Somos responsáveis pela execução do sprint e pelo gerenciamento de tarefas operacionais. O gerente de projeto por parte do cliente é realmente responsável pelo resultado geral do projeto. Nossa experiência diz que, para obter um resultado / MVP aceitável, testar hipóteses em alguma área funcional de um sistema de informações futuras, são necessários 3-4 sprints. Este é um período de tempo e trabalho razoavelmente grande. E lembre-se, dissemos anteriormente que o período de automação esperado agora é de 3 a 4 meses? Não, geralmente não nos importamos, podemos trabalhar com esse prazo, mas não sem a ajuda da equipe de um cliente.

O cliente que percebe o Agile como uma metodologia progressiva, porque é ouvido um entendimento diferente. Ele quer que citemos um cronograma específico, um orçamento específico, para que possamos gerenciar todo o ESCOPO do projeto, mas ao mesmo tempo fazer tudo acontecer "por via aérea".

Raramente existem gerentes de clientes prontos para assumir a responsabilidade pelos resultados do projeto. Muitas vezes, há uma substituição de conceitos - quase uma cachoeira clássica começa a ser chamada de "Edge", apenas com apresentações e exibições de resultados intermediários a cada duas semanas. E aqui estamos avançando sem problemas para o próximo caso, usando a metodologia híbrida.

O híbrido economiza?

A situação é semelhante ao caso anterior - o proprietário deseja iniciar o MVNO completo, além do principal tipo de negócio. O cliente tem prazos apertados e o projeto de lançamento do MVNO está vinculado a vários projetos de automação interna relacionados.

O cliente impõe restrições significativas ao orçamento, ao cronograma do projeto e requer a integração dos sistemas Forward com os sistemas de informações internos usando o Oracle DBMS. Além disso, como Lançado o MVNO completo, é necessária a compra, instalação e configuração de equipamentos de telecomunicações. O trabalho será em conjunto com a equipe de TI do cliente e várias equipes de outros contratados.

O projeto está começando, uma carga muito grande em nossa equipe. Temos que trabalhar com refino, nos comunicar muito de perto com os colegas. A composição das tarefas nos sprints muda muito dinamicamente, o cliente está envolvido no projeto e o flexit não é menos uma tarefa do que adiciona.

O resultado do projeto é positivo. Foi difícil e muito estressante, mas a funcionalidade mínima para iniciar o MVNO foi implementada o mais rápido possível, especificada pelo cliente na declaração de trabalho.

Restrições de tempo e orçamento apertadas, alto envolvimento do cliente e uma abordagem flexível para a formação de um pool de tarefas do sprint são uma boa reserva para a conclusão bem-sucedida do projeto. A principal característica deste projeto é a sincronização de sprints de todas as equipes que lançam um sistema de automação.

Quais projetos não levamos para o trabalho?

Baixo nível de conhecimento em design

Para nós, a alfabetização de projetos é expressa principalmente na presença de experiência na implementação de projetos com funcionários do cliente, clientes funcionais, tomadores de decisão e RP do cliente. Fazemos uma avaliação na fase das negociações iniciais. Tentamos nos comunicar com o DM e o RP pessoalmente. Se a experiência não estiver clara na comunicação, podemos perguntar diretamente.

Às vezes, o tomador de decisão não tem formação em TI, ele entende mal o que é desenvolvimento de software, a integração de diferentes softwares entre si, mas, ao mesmo tempo, o tomador de decisões tem muitas ambições. Esse tomador de decisão pode considerar que a automação é simples, rápida e barata, e o fornecedor e o integrador cobram dinheiro pelo ar. Durante as negociações, essa atitude é fácil de ver. É importante se existem pessoas competentes no ambiente do Mestre e como elas podem influenciar o Mestre. Se há pessoas com experiência em TI e o tomador de decisão as ouve, confia, isso aumenta as chances de entrarmos no projeto.

Você pode trabalhar com aqueles que não têm experiência no projeto, mas que estão interessados no resultado, mergulham nas tarefas e usam a experiência de colegas e contratados.

Você não pode trabalhar com gerentes teimosos, orgulhosos e surdos.

Requisitos inadequados

No estágio pré-projeto e TK, você pode entender o quão adequados são os requisitos para o orçamento declarado. Atitude inadequada em relação aos termos, o dinheiro é um sino importante e os riscos gerenciais, que fluirão para os riscos do projeto, porque as expectativas do cliente não serão justificadas. A conclusão de alta qualidade desse projeto é muito difícil.

O caso real: eles prepararam uma venda por um ano, conduziram um projeto preliminar e prepararam a documentação. Mas, de repente, o cliente anunciou na licitação as condições sob as quais os riscos do trabalho eram grandes demais, e nos recusamos a participar da competição de fornecedores. Perdemos uma quantidade significativa de tempo para o trabalho preliminar, mas era errado correr riscos e entrar no projeto nos termos estabelecidos no concurso.

Outro exemplo: o MVNO é lançado, os requisitos para a funcionalidade de um sistema de informação são estimados em vários milhares de pontos. Esses requisitos são compilados com base na experiência dos operadores em todo o mundo e não se correlacionam bem com as condições comerciais deste operador. Além disso, os proprietários significam que o lançamento do MVNO é um tipo de startup em que não está planejado investir uma grande quantidade de fundos. Nossa experiência diz que uma lista de mais de 100 requisitos seria normal nessa situação. Para simplificar esses milhares de requisitos e fornecer a cada resposta uma indicação da documentação da plataforma Forward, esses são custos de mão-de-obra que não serão pagos, a julgar pela atitude do cliente em relação ao orçamento do projeto.

Baixa qualificação de especialistas técnicos do cliente

A qualificação do departamento de TI do cliente não é um problema em si, se isso é suficiente para o funcionamento do negócio. Os problemas surgem quando pessoas pouco qualificadas são atendidas com tarefas críticas em um projeto de automação, argumentando que "temos nossa própria equipe de TI, deixe-as trabalhar".

Se você tiver sorte, como resultado do projeto, o departamento de TI do cliente aprimorará as competências e lidará com as tarefas. Mas pode não ter sorte. Mas nem sempre é possível conversar de perto com artistas comuns, para entender suas habilidades e motivação na fase inicial das negociações.
A baixa qualificação da equipe do cliente não é um fator de bloqueio, mas esse é um motivo sério para pensar e reavaliar todas as condições de interação com o cliente.

O próximo artigo é sobre riscos.

Grandes projetos corporativos são sempre riscos financeiros e de reputação. Então, lançaremos a segunda parte do artigo e falaremos sobre riscos do ponto de vista do contratante de automação.

Enquanto isso, convidamos você nos comentários para compartilhar sua experiência sobre as dificuldades e os problemas nos projetos!

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