Author Archives: Jesuíno Lopes

  • 0

SAP e Kanban: um Case Pioneiro no Brasil

A operação de um SAP ou outro sistema integrado de gestão empresarial (ERP) naturalmente envolve solicitações de diferentes áreas clientes para centros de serviços compartilhados (ou centros de competências). O processo de desenvolvimento das soluções é normalmente formado por etapas bem demarcadas, com diferentes interessados e participantes. Tem caráter multidisciplinar e costuma conviver com frases nada agradáveis como:

“O problema é que o desenvolvimento é lento e há poucos desenvolvedores!”

“O problema é na definição dos requisitos!”

“Depois de pronto, o cliente demora muito a testar!”

Em algumas empresas, as áreas possuem multiplicadores, usuários-chave, ou até mesmo equipes dedicadas a configurar o negócio na plataforma. Se, por um lado, isto traz agilidade, pode trazer dificuldades também. O nível de autonomia de atuação de um demandante, justificado pela sua urgência e pela necessidade de atender regras específicas, pode gerar duplicação de soluções (devido a falta de sinergias e reusos) e um nível de customização que cobrará seu preço no custo de manutenção e de atualizações. O negócio cria, sem saber, uma grande dívida técnica.

Estabelecer um processo conhecido por todos os participantes e adotar práticas de governança não é nada fácil, mas muito necessário. Os obstáculos são os mais diversos, a começar pelo interesse de independência dos diferentes demandantes. Além de métodos e ferramentas, será necessário habilidade, pragmatismo e coragem para que o CIO possa manter uma plataforma que não se torne um peso no custo do negócio e um elo fraco no value stream. Sim, um elo fraco, pois não conhecer e demonstrar bem essa cadeia de valor com sua importância e necessidades resultará em vários problemas como:

  • dificuldades de coordenação estratégica para os times;
  • dificuldade de capacitar os profissionais;
  • alto turn-over;
  • dependência técnica de alguns profissionais (real ou assim percebida pela companhia);
  • dificuldade de identificar e gerir a capacidade do time;
  • falta de lead-times conhecidos;
  • falta de padrões;
  • dificuldade para melhorar processos;
  • feudos de poder.

Em paralelo, as empresas enfrentam o desafio da necessidade de diversificar o portfólio de produtos para atender um mercado cada vez mais segmentado – as plataformas e seus processos precisam ser ágeis e flexíveis. Afinal, foi para isso que criamos os centros de serviços compartilhados, não é mesmo?

Tudo isso somado e temos o maior dos pesadelos para a Tecnologia: gerar a percepção de ser um empecilho às necessidades do negócio.

Vamos descrever um caso pioneiro no Brasil, que foi tema de apresentação na ASUG (Americas’ SAP Users’ Group): como a utilização de práticas ágeis do Kanban e Scrum em um Centro de Serviços Compartilhados do SAP trouxe bons resultados num cenário complexo de uma grande empresa, que exigiu ações combinadas e reorganizações estruturais.

Este caso ocorreu em um momento onde equipes multidisciplinares começariam a trabalhar juntas. Era preciso formar um time único e a jornada passaria de buscar entender o processo atual a ter indicadores definidos. Uma premissa era não fazer a gestão através de cronogramas e atividades. A meta era construir um time em torno de um objetivo único de criar um processo de gestão das solicitações.
sap1

Na etapa inicial, a própria equipe do Centro de Serviços Compartilhados fez um levantamento do processo de trabalho: o propósito do time, quem eram os envolvidos, o que cada um está fazendo, os limites de até onde ia o trabalho, etc. Com isto, geramos a primeira versão do quadro Kanban. Foi o início da gestão visual e tivemos resultados imediatos: visualização gráfica do sistema, classificação de demandas e definição dos estados iniciais de trabalho.

Para criar um espaço de discussão e aprendizado, havia as daily meetings — encontro rápido diário onde se trocava status das solicitações atuais e das metas diárias. A métrica inicial era o fluxo acumulado — quantidade de demanda por estado.

Com o alinhamento básico do time concluído, já era possível inserir novos conceitos. Antes, era preciso classificar bem as solicitações de acordo com o valor que agregavam ao negócio e aprender a quebrar o objetivo desejado em histórias menores — conceito fundamental para dar agilidade ao sistema. O time passou a identificar o que era “Evolução” e o que era “Produção”.

Após novas discussões, o quadro Kanban passou a representar a limitação da capacidade de cada etapa do processo e o conceito de que as atividades só podem ser “puxadas” se houver “vaga” para realizá-las. Resultado: alinhamento de expectativas de prazos e entregas.

Além de políticas de trabalho, ferramentas como User Story Cards, avatares e novos ritos (planning e reviews) foram introduzidos. A participação dos clientes foi fundamental e ocorreu principalmente nos plannings, onde se realiza a quebra das histórias e definição de critérios de aceite, e nos reviews, onde se apresenta as entregas.

A próxima etapa do time foi inserir a “Retrospectiva” nos seus ritos. Neste estágio, o próprio time definia o que começar, parar ou continuar a fazer para evoluir seu processo, além de conhecer o seu lead-time.

Como resultados da adoção dessas práticas, destacamos:

Identificação de Valor e Priorização

A participação ativa do cliente e a quebra de histórias fez com que as funcionalidades que mais adicionavam valor ao negócio fossem feitas primeiras, da forma mais simples e ágil possível. Tudo com transparência e consenso entre os vários demandantes.

Paradigmas Mudam

O ambiente mais participativo e as políticas de trabalho, além de promoverem uma melhor gestão do conhecimento, quebram feudos de poder e promovem uma verdadeira reorganização espontânea. Tempo ocioso não é para ser ocupado necessariamente com solicitações, mas pode ser usado para melhorar o seu processo interno – há que se afiar o machado!

Mitos Caem

A gestão visual e os ritos ajudaram a constatar que o “gargalo” não era o desenvolvimento (testemunhamos arrependimento de quem o culpava).

Redução de Estoque

Eliminamos em muito a quantidade de código que se gerava sem um teste sequer e que era, muitas vezes, abandonado.

Otimização do Processo

Novamente a gestão visual, os ritos e as políticas de trabalho promovem uma padronização do processo permitindo sua melhoria contínua.

Por fim, longe de definir fórmulas, o objetivo foi compartilhar o quanto buscar um modelo lean de trabalho com conceitos simples pode ser muito eficaz para tratar questões da nossa era do conhecimento, com resultados concretos para os negócios.


  • 0

Chief Collaboration Officer – CCO: você acha que sua organização precisa de um?

Com as organizações buscando mais performance e agilidade, o tema da colaboração está cada vez mais ganhando espaço. Mas fomentar a colaboração sem disciplina e método pode ser contrapruducente.

Na edição de janeiro-fevereiro da HBR, a colaboração é abordada pelo aspecto dos impactos que ela pode trazer se não for bem conhecida e administrada. A partir de pesquisas, os autores constataram uma relação direta entre os profissionais que são muito requisitados pelas equipes e o impacto em sua produtividade e nos times que influenciam. O resultado dessa colaboração não administrada e excessiva é a falta de engajamento, insatisfação, um consequente aumento de turnover e perda de talentos.

Mas como tratar o tema? Antes é importante entender os tipos de “recursos de colaboração” que uma pessoa pode oferecer a outra para gerar valor.

O autor classifica em informacional, social e pessoal. A informacional é aquela formada de conhecimento e habilidades e que, portanto, podem ser registradas e compartilhadas. A social se refere à possibilidade de usar a sua posição e acesso em uma rede de relacionamentos. Já a pessoal é a colaboração caracterizada pelo uso do tempo e energia de um profissional.

Ao realizar a colaboração social e informacional, não se esgota a oferta desses recursos, já a pessoal reduz a capacidade de um indivíduo executar seu próprio trabalho. E aí estaria a raiz dos impactos. Um profissional muito acessado e que usa seus recursos pessoais em excesso para colaborar com outros pode começar a levar trabalho para casa, a ter sua performance impactada, poderá transformar o que seria um grande time em um grupo de baixa performance ou pode virar um talento a incrementar o turnover da organização.

Para tratar o tema, o autor sugere então uma redistribuição do trabalho e uma recompensa para a verdadeira colaboração. Como acredito que estamos falando essencialmente de criar uma nova cultura, procurei agrupar as recomendações do autor em aspectos de comportamento, sistemas e símbolos.

Para a redistribuição do trabalho, o artigo coloca como primeiro passo conhecer a demanda e oferta das requisições entre os indivíduos. O tipo, o volume, origem e destino.

Uma vez conhecido esse fluxo, algumas iniciativas poderiam atuar em um comportamento mais adequado ao fluxo de requisições. Incentivar dizer “não” quando adequado, filtrar e priorizar as requisições e buscar incluir outras pessoas quando houver necessidade.

Organizações com muita aversão ao risco e que estimulam solicitações de aprovação e revisão, têm aí uma oportunidade de redução de requisições ao adequar essa demanda.

Se houver oportunidade, delegar fará diferença – times de suporte e coordenadores não poderiam assumir mais decisões?
Além disso, promover um espaço físico que favoreça proximidade em funções altamente interdependentes pode ajudar na colaboração informacional e social e na formação de um hábito de menos e-mails e menos reuniões!

Ainda no aspecto cultural, sistemas também podem ajudar em administrar o fluxo de requisições. A mesma colaboração se inserida em um processo formal de um treinamento ou coaching dentro da organização, por exemplo, tem um efeito mais motivador nos indivíduos do que de uma forma ad-hoc. O artigo apresenta também um case na Dropbox que reflete uma revisão nas normas de e-mails e convites de reunião. Foram suspensas por 2 semanas as reuniões recorrentes, fazendo com que após esse período as necessidades de requisição fossem repensadas.

Uma revisão de estrutura pode ser efetiva. Considere criar papéis que podem organizar demandas, reduzindo gargalos ou conectando pontos mais rapidamente. Um caso citado onde hospitais passaram a contar com enfermeiras em andares com foco em receber e direcionar requisições é uma boa analogia com o cenário “C” do artigo do Fabricio sobre melhorar performance do time), onde um ente externo é inserido em um sistema para melhorar sua performance.

E não menos importante o aspecto da recompensa que sempre remete à frase “diga-me como me medes que te direi como me comporto”. Nesse sentido, premiar a assistência ou a colaboração passará a motivar aqueles que performam bem, mas nem sempre colaboram. É fácil identificar os líderes funcionais, mas pode ser necessário um pouco mais de esforço para entender os fluxos de colaboração e então premiar também àqueles que estão gerando valor dentro da organização e que muitas vezes passam despercebidos.

O autor não deixa de citar o suporte de ferramentas de tecnologia nesse processo. Assunto que mereceria um artigo só para esse aspecto. Fala do uso do slack e chatter (salesforce.com) que promovem muito bem a colaboração informacional e social. Além disso, cita a Volometrix que ajuda no mapeamento de um fluxo de informação organizacional permitindo uma atuação mais consciente sobre o processo de interações.

Ou ainda a última versão do Basecamp onde um botão “snooze button” para que o profissional posso gerenciar o fluxo de solicitações que chega a ele.

Quando enviei este artigo para o Fabrício, convidando a pensarmos no que as práticas ágeis podem ajudar na formação de uma cultura de colaboração, ficamos pensando em qual seria o segredo das metodologias ágeis, que são completamente baseadas em trabalho colaborativo, para funcionarem tão bem e de forma simples há tantos anos, sem os problemas mencionados no texto. Vou compartilhar parte de nosso exercício.

Por exemplo, imagine um colaborador ou uma subequipe de conhecimento específico, que tenha que atender a vários projetos que usem Kanban. Esses projetos poderiam usar um quadro kanban por subtimes de conhecimentos específicos (do post 5 exemplos de quadros kanban para TI).

O conceito de limitar o trabalho em andamento seria a solução para esse colaborador (ou subequipe) dizer “não, não posso mais pegar atividades deste projeto” e evitar a sobrecarga de trabalho.

Se fossem projetos com Scrum, uma carga excessiva de trabalho provavelmente apareceria como impedimento ou uma história demorando a ser entregue (o que seria identificado num gráfico de burndown).

Logo na próxima reunião diária, ou seja, no próximo dia útil de trabalho, isto ficaria claro e o Scrum Master entraria em ação para negociar a priorização com as partes interessadas, do ponto de vista para a empresa, entre todas as frentes demandantes do recurso (que continuaria focado no seu trabalho, sem participar desta negociação).

Aliás, é por isto que a autonomia que as metodologias ágeis pregam é tão importante para o time, para o Product Owner e para o próprio Scrum Master. Ela diminui muito a necessidade de consultar (e interromper) pessoas para tomar decisões.

Seguindo no Scrum, o ritmo dos sprints e o agendamento estável das suas cerimônias (planning, daily scrum, review e retrospectiva), permite que as pessoas se organizem previamente e sejam acionadas adhoc ao mínimo.

Mesmo no Kanban, que segue um fluxo contínuo sem necessariamente esse ritmo cíclico dos eventos, uma boa alternativa poderia ser usar um método de organização de atividades como este do texto Como fazer o seu dia render.

Um aspecto que o artigo cita como ponto positivo e também faz parte da filosofia ágil: sempre que possível, trabalhar fisicamente juntos. Principalmente enquanto a cultura de trabalho colaborativo está sendo formada, isto é fundamental e normalmente é simples de ser colocado em prática.

Finalizando, gosto de reforçar que as metodologias ágeis são muito mais do que as ferramentas e as práticas usadas (os famosos quadros e post-its). Há método e disciplina fortes que as sustentam e é por isso que funcionam.

Voltando ao artigo e ainda falando em cultura, um símbolo é citado ao final. Trata-se da possibilidade em um futuro próximo da existência de um “Chief Collaboration Office”. Sem dúvida o desafio é grande e talvez, para grandes corporações, seja realmente necessária uma figura central para ilustrar o patrocínio executivo ao trabalho colaborativo, mas há também que se evitar o risco de que essa seja a função de um só ou de um departamento – me faz lembrar o tratamento muitas vezes dado à questão da inovação nas empresas. Prover a cultura é papel da organização e cada um de seus líderes tem como missão mais importante ser um facilitador do ambiente para geração da cultura adequada. E já temos muitas práticas comprovadas que podem ser escolhidas para a realidade de cada um. Basta começar.

E você, acha que sua organização precisa de um CCO?

Um abraço,

Jesuíno Lopes
Diretor de Plataformas Digitais
ViaDigital.Solutions


Receba nosso Boletim

Grátis, diretamente em seu email, artigos sobre métodos de startups aplicados a soluções empresariais.