A intranet unida do grupo de empresas M.Video-Eldorado ganhou o prêmio principal do Russian Intranet Awards em 2020 e os prêmios prata de Intranet e Digital Workplace . Este produto interno foi desenvolvido do zero em seis meses. O fato de que isso foi feito dentro de um prazo e nível de valor reconhecido interna e externamente é o resultado de uma abordagem de produto e práticas ágeis. Contaremos por que eles foram escolhidos e quais elementos dessa metodologia se tornaram fundamentais.
Fundo
Em 2018, a M.Video e a Eldorado se fundiram, que naquela época eram as maiores varejistas de todo o espectro de eletrônicos e eletrodomésticos na Rússia. A empresa combinada emprega cerca de 30 mil pessoas. Existem mais de mil lojas nele, que operam em mais de 200 cidades da Rússia.
É preciso muito esforço para criar uma empresa unificada. Por muitos anos, M.Video e Eldorado formaram independentemente suas culturas corporativas e não eram nada parecidos. E agora, para quase 30 mil funcionários, era necessário divulgar não só uma estratégia única para cada marca, mas também uma visão única do grupo de empresas.
Praticamente em todas as grandes empresas, e agora no grupo, utiliza-se activamente uma intranet, que funciona como principal fonte de notícias para os colaboradores e, consoante a sua maturidade, consolida não só a comunicação mas também vários níveis dos processos de negócio.
Além disso, possui diversos serviços de funcionários implantados. Seu público mensal ultrapassa 23 mil pessoas, os principais usuários são vendedores e diretores de loja, chefes de bloco de varejo, além da gerência de linha e média da central. E as seções mais populares são indicadores de motivação financeira, serviços de autoatendimento, um gerenciador de tarefas integrado, um bloco de notícias e pesquisa por pessoas.
Por que o grupo "M.Video-Eldorado" precisa de uma intranet unificada?
Em princípio, a resposta a esta pergunta é óbvia. O objetivo da intranet é maximizar o potencial humano da empresa. Para trabalhar com a máxima eficiência e receber não só um salário, mas também a satisfação do trabalho, é preciso saber como vive a empresa, como está se desenvolvendo o seu negócio, quais os valores que professa e saber encontrar perspectivas para você e sua equipe. E tudo isso está disponível na intranet.
Para priorizar corretamente, era o princípio de Pareto um dos principais na organização da carteira do futuro produto. Na prática, isso é conseguido organizando uma alta disponibilidade de 20% das informações-chave sobre os funcionários e a empresa, o que dá 80% da eficácia.
Por exemplo, 10 métricas chave de varejo disponíveis em um smartphone na palma da mão de um diretor de loja serão mais convenientes para tomar uma decisão operacional do que um relatório multinível em um sistema de BI em um PC. Certamente é necessário um relatório detalhado, mas no início você precisa entender o quadro geral, e isso é sempre uma informação generalizada e compacta.
As tarefas que o grupo de empresas está a resolver através da intranet: informar eficazmente os colaboradores, garantir o seu acesso às principais informações, definição de tarefas de elevada qualidade, disponibilidade das principais métricas e serviços e, por fim, a oportunidade de utilização do conhecimento base e experiência da empresa e colegas.
Formulação do problema
Antes da fusão, cada empresa usava sua própria plataforma de intranet. Eles eram SAP FIORI e SharePoint. Cada um deles é uma boa ferramenta, permitem agregar e visualizar informações, colocar serviços. Mas nenhuma das plataformas nos convinha em termos de escalabilidade dos custos de suporte.
Nosso objetivo era criar um espaço de comunicação fundamentalmente novo para os funcionários. Mas não queríamos desenvolver tudo do zero, imediatamente consideramos esse caminho muito caro. Portanto, decidiu-se criar um híbrido - para usar um aplicativo independente para a "frente" que se integra com dados mestre de sistemas adjacentes e extrai deles as informações necessárias.
Um dos "chips" técnicos dessa solução foi a organização de seu próprio cache de aplicativo com os dados mais críticos. Por um lado, isso possibilitou organizar alta disponibilidade, autonomia e velocidade de resposta, por outro, livrou os sistemas mestres de um grande número de chamadas.
Para se adequar ao mercado , primeiro conversamos com os usuários. No início, é especialmente importante entender o que eles exigem do aplicativo ou serviço. E entrevistamos um grupo representativo. Geralmente, perguntamos o que é importante para eles organizarem um trabalho eficaz, o que não lhes convinha nos serviços antigos, de que funcionalidades ainda precisam.
Importante: não tentamos “vender” uma ideia ou produto e falamos o menos possível sobre a intranet. Nesses casos, os colegas podem ser tendenciosos e dar respostas socialmente esperadas.
Se o objetivo é criar um bom aplicativo, você precisa obter respostas honestas, agrupá-las em uma matriz, identificar as maiores coincidências nela. Desta forma, será possível saber exatamente o que os usuários precisam e quais os objetivos estratégicos que o cliente deseja atingir.
A segunda fase de preparação foi a "venda" da ideia à gestão. Os principais gerentes da empresa, os principais clientes e patrocinadores do projeto, entenderam perfeitamente que as intranets M.Video e Eldorado deveriam ser combinadas. A rigor, a iniciativa, a demanda por inovação, veio deles. Mas o fato de o projeto ter afetado todos os aspectos da vida da empresa e todas as unidades estruturais deixou sua marca.
Precisávamos encontrar suporte em todos os setores. E nos comunicamos ativamente com os chefes das divisões estruturais, explicando a essência do projeto e falando sobre nossas abordagens. Transmitimos a cada um dos "business angels" uma lista de tarefas enfrentadas pela empresa e cálculos de como o projeto afetaria sua solução. O trabalho inicial de um product owner é muito semelhante ao de um empresário que deve provar a viabilidade de sua ideia aos investidores.
Valeu a pena quando o MVP estava pronto e as métricas confirmaram a viabilidade da ideia. Nesta altura, quase todos os gestores sabiam do projecto, defendemo-lo com sucesso e a solução de intranet direccionada foi incluída no portfólio de iniciativas digitais da empresa, tendo recebido grandes investimentos.
Abordagem do produto
Tomamos a decisão de aplicar uma abordagem de produto - para desenvolver as necessidades e os usuários finais e encontrar pontos internos de crescimento do negócio. Isso tornou possível estreitar o conceito, achar mais fácil navegar no interesse dos clientes empresariais e evitar conflitos de interesse.
No início, selecionamos o assistente de loja como a pessoa-chave. É a força de vendas o elo chave na cadeia de valor. Assim, o produto nacional tornou-se atrativo para investimento, englobando e valorizando métricas de negócios que estão diretamente atreladas aos vendedores e gerentes de loja.
A propósito, nem todos no escritório central apreciaram essa mudança, já que para essa pessoa (gerente de escritório) no estágio de MVP, não tínhamos recursos significativos. A escolha de uma pessoa-chave é crucial para o estágio MVP. Esse foi um dos desafios da equipe de gerenciamento de produtos.
Documentos básicos
Para criar tal sistema, tivemos que formar sua funcionalidade. Para isso, usamos a estrutura de mapeamento de impacto . Ele apóia os princípios do produto em design de alto nível e permite que você encontre relações causais entre os objetivos do produto e suas soluções funcionais.
Com base no "mapa de influências" compilado, formamos uma visão de produto- um documento especial que descreve os objetivos principais, o impacto do produto no negócio e no público-alvo. Este documento é a ferramenta de desenvolvimento de produto mais importante. É sempre atualizado, constantemente atualizado para refletir o estado atual do projeto, e é regularmente apresentado aos clientes interessados e à equipe de desenvolvimento.
Uma visão de produto também é necessária para criar uma lista priorizada de requisitos ( backlog de nível superior ) que se aplicam ao produto que está sendo desenvolvido. O product owner determina as prioridades nele. Este documento sincronizará as expectativas do projeto do lado da administração e dos clientes. E ela, como a visão, deve ser constantemente atualizada.
Scrum
A complexidade do nosso projeto reside em um grande número de informações introdutórias. Tínhamos também um contexto de negócios atípico, sobrecarregado pela recente integração de duas grandes empresas e a necessidade de implementar funcionalidades atípicas para uma intranet (por exemplo, definir tarefas massivas para campanhas de marketing e outras atividades nas lojas).
Eles se sobrepunham a tarefas desconhecidas no estágio inicial de desenvolvimento, que, como bem esperávamos, apareceriam em estágios subsequentes.
Uma maneira de lidar com a incerteza em tais casos era combinar a abordagem ágil e o framework Scrum.
Um dos pontos fortes do Scrum é a transparência que ele fornece. Mostra a produtividade real da equipe, dá previsibilidade de tempo e retorno sobre os resultados. Isso é especialmente importante quando a funcionalidade está sendo implementada pela primeira vez, quando vários caminhos são possíveis. Você reduz os ciclos de entrega de peças de trabalho de um produto com muitas iterações curtas e, assim, evita erros de design importantes.
Todas essas vantagens não significam que o Scrum pode ser usado como uma ferramenta universal. Não - provavelmente será inútil em estruturas com uma hierarquia rígida, onde os gerentes não estão prontos para se comprometer e dar liberdade e espaço de decisão para a equipe.
Deve-se ter em mente que o Scrum exige alta qualificação, disciplina, esforço e até paciência da equipe. Mudar para esta estrutura pode levar a mal-entendidos e conflitos se for errado "prepará-lo".
Juntamos as fileiras daqueles que foram "queimados" pela interpretação incorreta da abordagem nos estágios iniciais. Como resultado, um terço das equipes de desenvolvimento foi perdido do lado do integrador de sistema que trabalhou no projeto: o gerenciamento permaneceu opaco e a carga nos desenvolvedores foi forçada.
Ao mesmo tempo, a própria equipe foi inicialmente dividida em "representantes do cliente" e "representantes da contratada". Isso acontece quando as pessoas não veem o significado profundo por trás dos eventos SCRUM e transformam tudo em uma formalidade. Isso geralmente é causado por falta de paciência, busca de lucro ou desejo de manter o status quo por aqueles que anteriormente trabalhavam de forma diferente.
O treino SCRUM “em batalha” levou-nos a erros tanto na definição das tarefas como no design e desenvolvimento, mas com a ajuda dele resolvemos também todos os problemas. Não importa o quanto você diga que o sprint inclui trabalho de refatoração e revisão de código, foi somente depois de várias falhas e dolorosa contemplação do volume de dívidas técnicas que a equipe decidiu planejar os sprints de forma ponderada levando esses aspectos em consideração.
Se você está indo apenas para esta estrutura - por favor, seja paciente, tente fornecer à equipe um equilíbrio onde 1 FTE de um funcionário experiente "serve" ou mentor 1 ou melhor 0,5 FTE de junho / meio e encontre um Scrum-master competente com uma formação técnica. Você pode mergulhar nos detalhes de nossa experiência aqui: parte 1 , parte 2 , parte 3 .
E, no entanto, Scrum permite que você tenha uma imagem real do que está acontecendo e faça os ajustes necessários no tempo.
Um foco estratégico bem definido e uma organização do fluxo de trabalho por meio de entregas incrementais, admissão de erros e conclusões oportunas nos permitiram alcançar resultados excepcionais no final. Trabalhamos em bugs, salvamos membros-chave da equipe, construímos um MVP em 3 meses e uma solução escalonável em 6.
Qual é o próximo?
Hoje nosso projeto e equipe continuam evoluindo. Descrevemos uma transição para a estrutura LeSS , recebemos um aumento múltiplo nas métricas e agora estamos mudando para o paradigma de um SuperApp intracorporativo.
PS: Nesta fase, realmente precisamos de programadores talentosos . Se você é assim, venha , vai ser interessante.