Category Archives: Bússola Digital

  • 0

Como Controlar a Qualidade no Mundo Ágil?

Em outras palavras, como fazer software rápido, mas fazer bem-feito? Afinal, uma vez que as práticas ágeis de desenvolvimento de software estejam em pleno uso na sua empresa por seus times, é bem provável que você encontre alguns problemas em relação ao processo de desenvolvimento:

  • novas releases quase sempre acompanhadas de novos bugs;
  • dúvidas se o esforço de desenvolvimento está indo para valor adicionado ao produto ou para manutenções corretivas;
  • não-conformidades e divergências em relação ao padrão corporativo (mesmo entre analistas de uma mesma equipe);
  • diferentes padrões de desenvolvimento e metodologia entre os times;
  • falta de sinergia entre as equipes e dificuldades para fazer um rodízio entre os analistas de times diferentes (afinal, cada equipe faz do “seu” jeito).

Uma solução tradicional seria montar um time de controle de qualidade para inspecionar os artefatos e testar as releases, apontar as não-conformidades, bugs e rejeitá-los. Simples, porém um paradoxo conceitual. Afinal, todo o ganho de agilidade nas entregas pode ser colocado em risco se deixarmos para descobrir, lá no finalzinho, que parte do software precisa ser refeita. Facilmente, para cada correção, podemos adicionar algumas semanas no prazo final. Ou, então, aquela correria de entrega final, com custos de horas-extras e a penalização motivacional do time, além de prejudicar a qualidade do produto (“testa aí, rapidinho…”).

É possível fazer diferente, com bons resultados. Podemos contar o caso, ocorrido numa grande organização, onde atuamos na causa-raíz do problema (a falta da cultura de testes e a baixa aderência à metodologia de desenvolvimento pelos desenvolvedores), e não apenas nos sintomas (artefatos com não-conformidades e bugs), focando na importância de se construir software com qualidade desde o início.

Em conjunto com a equipe de qualidade, criamos indicadores para acompanhamento das entregas e do trabalho dos desenvolvedores, tangibilizando os pontos fortes e os pontos de melhoria. Livres do rigor acadêmico, alguns indicadores eram simplesmente valores booleanos que indicavam se uma prática era seguida. Eles foram divididos em quatro grandes temas:

  • Processo de Desenvolvimento de Software
  • Produto
  • Eficiência e Melhoria Contínua
  • Cliente/Negócio

Fizemos uma apresentação dos indicadores para todos os desenvolvedores na reunião geral da Gerência de Desenvolvimento de Produtos, mas a receptividade deixou a desejar: alguns desenvolvedores sentiram-se “auditados”. Sempre acreditando no trabalho colaborativo, fizemos encontros com cada equipe para esclarecer dúvidas e reforçar o foco na melhoria do processo, e não no controle individual de desempenho.

 

Também para melhorar a comunicação com os times, criamos um rito ao final de cada sprint, a Retrospectiva Técnica, em que o time de qualidade apresentava para cada célula de desenvolvimento a sua planilha de indicadores, e eram levantados pontos de melhoria e respectivos planos de ação.

Após dois anos de trabalho, tivemos sólidos resultados.

Melhoria da Qualidade do Software Produzido

Redução direta do custo do desenvolvimento. A relação de causa e efeito foi visível: os times mais aderentes à metodologia de desenvolvimento tinham menos defeitos no software produzido. Além disso, identificamos que estava ocorrendo muito trabalho em correções de funcionalidades que já tinham sido dadas como concluídas. E, pior, sem reflexo em nenhuma métrica de acompanhamento, já que o indicador de defeitos, inicialmente, só monitorava sistemas em Produção. Mudamos o conceito do indicador para abranger as manutenções corretivas em todas as funcionalidades concluídas pelos times, mesmo que ainda não estivessem em Produção. Assim, cobrimos este aspecto da qualidade já na fase de desenvolvimento. Descobrir defeitos mais cedo sai mais barato.

Criação de Comunidade de Práticas: Fórum de QA

Conseguimos um compartilhamento contínuo de conhecimento tácito entre os participantes através de encontros periódicos. As reuniões de retrospectiva técnica foram fundamentais, pois permitiram o compartilhamento de experiências e debates, incluindo “lavagem de roupa suja”, com os desenvolvedores apresentando suas insatisfações e críticas com a metodologia. Isto permitiu uma melhoria contínua do processo. Tanto que elas evoluíram para uma comunidade de práticas, chamada de Fórum de QA, formada por representantes de todas as equipes de desenvolvimento, onde também tivemos troca de experiências, discussões sobre dificuldades, sugestões e dúvidas técnicas que ocorriam no dia-a-dia dos times.

Ampliação do Uso dos Cenários de Testes

Na metodologia de desenvolvimento da empresa, um documento muito relevante era o Cenários de Testes, escrito pelos próprios desenvolvedores, no formato “Given-When-Then”, de especificação comportamental (BDD). Com o passar do tempo, vários outros pontos de utilização dos documentos dos cenários de testes, não imaginados inicialmente, foram identificados:

  • na validação do PO técnico;
  • na validação do cliente;
  • na review;
  • na ambientação de novos colaboradores;
  • no apoio à equipe que cuidava da operação do software em Produção;
  • na definição dos cenários para testes de performance.

O fato de os documentos serem criados na plataforma Google Docs, disponível via internet para todos os usuários da empresa, e não só os da Tecnologia, viabilizou e liberou todo o potencial de uso dos artefatos, que se tornaram a principal forma de compartilhamento e reuso de conhecimento explícito na metodologia.

Automatização dos Testes

À medida que a cultura de desenvolvimento orientado a testes (a partir dos cenários de testes) foi absorvida pelos analistas, começamos a buscar soluções para automatização. Ao final do trabalho, todos os times já executavam testes automatizados: tanto os unitários, como também os testes de interface. Testes de regressão que levavam algumas horas para serem feitos manualmente, passaram ser executados em cerca de 20 minutos. Com os deploys constantes de seus produtos, isto representou uma redução significativa de custos para a empresa.

Simplificação da Planilha de Acompanhamento dos Indicadores

Ao longo do tempo, o acompanhamento dos indicadores foi simplificado, e reduzimos os indicadores para apenas quatro: um para cada tema. O objetivo foi focar no essencial e tornar a metodologia de acompanhamento mais leve.

Pesquisa de Satisfação com a Metodologia de Desenvolvimento

Tivemos 73,9% de avaliações positivas, respondidas pelos desenvolvedores e Scrum Masters.

Apoio e Patrocínio são Fundamentais

Mudar cultura é complexo. A alta gerência precisou atuar em alguns momentos como mediadora entre as equipes de desenvolvimento e a Equipe de QA, mantendo saudável a relação entre os analistas envolvidos. Sem este apoio, a iniciativa teria fracassado, sem dúvidas.

Nossa experiência mostrou que é possível fazer software rápido e bem-feito. Trabalhar na causa-raíz do problema, na cultura de desenvolvimento, é uma jornada árdua, que exige paciência e evangelização, mas compensa com resultados concretos, duradouros e, sim, mensuráveis.


  • 0

O Manifesto do Trabalho Colaborativo

Você trabalha de forma colaborativa com suas equipes, pares e superiores? Muito provavelmente, a resposta será sim. O trabalho colaborativo e o trabalho em equipe são muito valorizados hoje em dia, e todos buscam trabalhar desta maneira. Mas será que isso acontece, de fato?

Nossa experiência mostra que a realidade não é bem essa. Nas corporações, principalmente, há muitos interesses em jogo. Por mais que os objetivos da empresa estejam bem definidos para a entrega de serviços e produtos, os departamentos envolvidos podem não estar em sintonia ou em harmonia. Muitas vezes, há vaidades envolvidas, disputas de poder, desalinhamento e uma cultura que faz com que os profissionais pensem primeiro em se proteger contra qualquer falha e deixar um “culpado” pronto para receber as “punições”.

Esses ambientes sufocam o potencial dos profissionais e das equipes: opiniões de valor não são ouvidas (muitas vezes nem faladas), talentos são reprimidos e pessoas se tornam frustradas.

Não há trabalho colaborativo que resista.

É necessário, antes de qualquer coisa, haver uma cultura adequada, um ambiente propício para o trabalho em equipe, que pode trazer muitos ganhos às empresas e aos profissionais, com a contínua evolução da produtividade, o engajamento, o comprometimento e a (auto) motivação com a consequente felicidade pessoal.

Por este motivo, pedimos licença para explicitar pontos importantes na habilitação da  cultura colaborativa, colocando-os no manifesto a seguir. Nossa intenção é fomentar a discussão para reforçar a transformação cultural necessária e implantar os pilares de sustentação desta forma de trabalhar, cada mais mais imprescindível nos dias atuais.

Manifesto do Trabalho Colaborativo

Equipes felizes com o seu propósito, apaixonadas pelo que fazem, entregando resultados com alta performance, numa cultura genuinamente colaborativa.

Propósito

Precisa ser definido, comunicado de tal forma que gere o engajamento desejado para o atingimento dos objetivos.

Objetivo:

Todos têm um objetivo comum, com metas claramente definidas e convergentes, e são regidos pelo propósito.

Resultados:

Os resultados esperados são coletivos e naturalmente são superados em qualidade e agilidade. A inovação surge espontaneamente.

Gestão:

A gestão estabelece e zela pelo engajamento no propósito e a direção clara a ser seguida em todos os movimentos (ações, reuniões, decisões, comunicações), mantendo a equipe com foco no rumo traçado – não dizendo como fazer ou estabelecendo controles para checagem. A equipe decide como chegar lá.

O gestor trabalha com regras do jogo em evolução constante, expectativas claras e transparentes, criando uma cultura de contribuição, incentivando a troca de ideias, opiniões e a participação das pessoas, provocando discussões construtivas, alto grau de engajamento e prazer, com autonomia e responsabilidade para experiências e aprendizados – sabendo que sucessos e falhas fazem parte da jornada. 

Liderança, porém, não é uma característica apenas da gestão. É um estado de espírito. É a internalização consciente, pelos membros da equipe, da esperada atitude.

Equipe:

A equipe comunga de um propósito e é definida pelo objetivo a alcançar e não pela estrutura hierárquica, centro de custo, área, departamento, unidades, diretorias ou organização.

A equipe é especializada ou multidisciplinar, experiente ou iniciante, e trabalha coletivamente na busca da solução dos problemas.

A equipe é autônoma, autorregulada, comprometida, assume suas responsabilidades para realizar suas atividades e conquistar os seus objetivos.

A equipe aprende continuamente (tanto em relação à técnica quanto ao lado comportamental), analisando suas métricas, adaptando e evoluindo seus processos, buscando a excelência de suas entregas, construindo e mantendo um ambiente eficiente, lúdico, saudável e feliz.

Pessoas:

As pessoas recebem bem os desafios e mudanças e o aprendizado é constante.

As pessoas conhecem as regras do jogo e participam ativamente contribuindo, trocando ideias, opiniões, com discussões construtivas, alto grau de engajamento e prazer, com autonomia e responsabilidade para experiências e aprendizados – vivenciando seus sucessos e falhas.

As pessoas dão e recebem feedback de forma aberta e madura.

 

Qual é a sua opinião? Concorda com estes pontos? Venha fazer a sua contribuição e assinar o manifesto! Vamos transformar a cultura, modernizando a forma de trabalho na era do compartilhamento e contribuição. Assine o manifesto:http://manifestocolaborativo.org/manifesto-trabalho-colaborativo/#respond 

 

Cláudio Barizon, Fabrício Fujikawa e Jesuíno Lopes são signatários do manifesto


  • 0

Práticas Ágeis: Para Cada Tipo de Paciente, uma Dose do Remédio

Para muitos é “ame-as ou deixe-as”. Para outros, elas são cultuadas e precisam ser seguidas à risca, quase como uma religião. Mas as práticas ágeis estão apoiadas em conceitos simples, com foco na interação das pessoas para solução de problemas e entregas de valor. Desta forma, sua adoção permite que você avalie quais melhores práticas se encaixam na sua necessidade e como as mesmas devem ser implantadas.

Particularmente, não acredito que exista uma “receita de bolo” para se utilizar em todas as situações. Existe um arsenal de práticas e metodologias que podem e devem ser utilizadas de acordo com o cenário encontrado em cada organização. Não se trata de implantar as metodologias ágeis para seguir a tendência atual, ou para solucionar todas as deficiências nas entregas de produtos ou projetos, mais especificamente os de Tecnologia. Trata-se de identificar e entender o problema que se quer resolver: falta de alinhamento estratégico, falta de comunicação com os clientes, falta de gestão do portfólio de projetos, inexistência de processo para criação de produtos, baixa qualidade da entrega, falta de processo de desenvolvimento de software, desmotivação da equipe e etc. Muitas vezes, uma combinação de vários deles ou de todos eles até. E os caminhos são diversos.

É sempre bom também contar com o patrocínio da alta gestão da empresa para uma mudança, mas, eventualmente, isso não acontece de início. Com relação às práticas ágeis, vender esta ideia para o board, nem sempre é fácil. Apesar dos conceitos simples, eles podem soar tão simples que não ganham credibilidade. E isso é normal. Então, como fazer? Bem, é preciso mostrar que funcionam! Nestes casos, vale montar um piloto e começar devagar, “comendo o mingau pelas beiradas”.

Temos alguns casos de sucesso para mostrar que a abordagem para adesão às metodologias ágeis depende de cada contexto, e que não adianta implantar indiscriminadamente, “goela abaixo”, as mais modernas práticas disponíveis de uma vez. Um caso que evidencia bem esta situação aconteceu em uma grande empresa de mídia. As práticas ágeis chegaram como uma boa novidade. Houve certo entusiasmo da alta gestão para seu uso, cuja promessa era garantir mais entregas de produtos em espaços de tempo cada vez mais curtos. Tudo o que eles queriam. No entanto, não houve patrocínio para uma mudança de cultura e processos que precisava permear todas as áreas, em não apenas a TI, no desenvolvimento de produtos. Mas foi a Tecnologia que efetivamente comprou a ideia e sua implantação, através da média gerência.

Os times foram envolvidos e se comprometeram com a mudança. As primeiras experiências não deram nem tão certo, mas o aprendizado adquirido e compartilhado mostrava claramente que o caminho era aquele. Interessante constatar o quanto as equipes de desenvolvimento identificaram-se com o novo processo e motivaram-se com ele. E esse foi apenas o início. Fundamental, porém, para embasar todas as demais mudanças que estavam por vir.

O cenário era complexo. A empresa, motivada pelas dificuldades e os desafios da indústria de mídia, passava por grandes mudanças: organizacional e estratégica, que fez com que a mesma investisse na troca de sua plataforma de publicação. A equipe de Tecnologia estava crescendo rapidamente e absorvendo novos profissionais, muitos deles mais juniores. Absorvia também novas ferramentas e não existia um processo maduro de desenvolvimento. Longe disso! A área de TI também sofria com os prazos apertados e as entregas não cumpridas. Portanto, apesar da necessidade de modernização urgente, não dava para se fazer tudo ao mesmo tempo. O risco de comprometer ainda mais as entregas e acabar de vez com a credibilidade da Tecnologia era enorme.

O início se deu com a adoção de metodologias ágeis para gerir as atividades da equipe de desenvolvimento: num primeiro momento o Scrum, com algumas pitadas do Kanban. Os resultados junto aos times foram animadores e vieram rapidamente: as entregas começaram a fluir e, cada vez mais, os clientes estavam mais próximos desta rotina, respirando os produtos. Em pouco tempo, o time de desenvolvimento virou a equipe do produto. Ótimo! Era este o ambiente desejado.

Hora de fazer mais mexidas, agora no processo de desenvolvimento: novos conceitos foram incorporados como a orientação a testes e o foco em qualidade. Mais adiante, foi criada a “cesta de indicadores de qualidade”, com o objetivo de medir o desempenho, aumentar a transparência junto ao usuário e tangibilizar melhor o aprendizado da equipe. Toda esta evolução feita paulatinamente e com a participação efetiva das equipes, exatamente para criar o estado de pertencimento e propriedade.

Desta forma o comprometimento, não apenas com o produto a ser entregue, mas com os processo e práticas garantiu que as mudanças ocorridas passassem a fazer parte da nova cultura corrente.

Mas tudo a seu tempo. Respeitando-se as limitações da empresa, da gestão e das equipes e levando-se em consideração o contexto e o momento corporativo. Não é problema se permitir fazer concessões às práticas ou métodos ou abordagens, desde que se respeite os conceitos fundamentais e o foco na conscientização de uma nova filosofia de trabalho participativa, transparente e colaborativa.


  • 0

A Culpa é da TI?

Entregas não realizadas, prazos não cumpridos, usuários insatisfeitos, oportunidades de mercado perdidas, executivos pressionando, cobrança, equipe desmotivada. Normalmente, sempre por “culpa da TI”. Este cenário é muito comum e a “necessidade” de se encontrar um culpado faz a corda arrebentar para o lado mais fraco. Este lado quase sempre é a equipe de Tecnologia, que muitas vezes, não é vista ou tida como estratégica e funciona como uma anotadora de pedidos, que precisa fazer as entregas a qualquer custo.

Nem sempre prazos apertados ou impossíveis, falta de definição dos requisitos, mudanças de escopo constantes e falta de comprometimento de outras áreas envolvidas são levados em consideração para se avaliar o melhor direcionamento para o projeto. Nada! O importante é encontrar logo o culpado e “passar o mico”. A bomba vai estourar na ponta e a ponta é exatamente quem vai fazer a entrega final, a TI. Estas equipes, muitas vezes, atuam com seus “heróis”, tentando recuperar o tempo perdido. Fazem de tudo, viram a noite, perdem os finais de semana e feriados. Mas, no final, não entregam, perdem o prazo ou geram produtos sem qualidade. O maior problema, porém, é a insistência em repetir esta sistemática. E isso se repete e se repete e se repete…  Não vai dar certo! Vai dar problema de novo e mais cobranças e desconfianças sobre a área de Tecnologia.

É isso que temos visto nas empresas por onde passamos. É um padrão. Obviamente, os CIOs se preocupam com esta situação, pois é sempre a sua área que está em xeque.  Mas, como dizia o poeta: “os heróis morreram de overdose”. A solução não está por aí. Por mais preparados que sejam os profissionais de tecnologia, é melhor deixar as missões impossíveis para os Vingadores nas salas de cinema.

Para obtermos resultados diferentes, precisamos fazer diferente! É importante olhar todo o processo e comprometer todos os envolvidos (e não apenas a TI), fazendo com que as áreas trabalhem e funcionem de forma colaborativa. Não é fácil na cultura de empresas que ainda insistem em encontrar culpados e, por isso, o trabalho precisa ser mais profundo. Ele passa por uma transformação e mexe na cultura, nas pessoas, e nos processos, para que todos entendam seu papel e se comprometam com a entrega final como uma equipe, independentemente da área em que atuam.

Parece simples, mas sabemos que não é tão fácil assim. Existem muitas questões envolvidas no ambiente corporativo: política, vaidade, metas dos executivos (normalmente, não convergentes), orçamento e etc., que acabam inibindo o comportamento desejado de colaboração e comprometimento com o mesmo fim. Muitas vezes, as equipes recebem a solução pronta a ser implementada. E este é o pior dos mundos. É muito importante que o time conheça a direção, a estratégia e tenha um propósito. Reunindo as competências corretas e, com o direcionamento adequado, a equipe vai encontrar as melhoras soluções. Ao fazer isso, conquista-se um dos maiores ingredientes do sucesso: engajamento.

O caminho para esta mudança passa por quebras de paradigmas e uso de práticas menos intuitivas, que compõem o arsenal existente de práticas ágeis. Desde que passamos a usá-las ou introduzi-las nas empresas, a realidade mudou para estas equipes. Mas, ainda assim, existe certa desconfiança sobre a utilização destas práticas: parecem frágeis, feitas “nas coxas” e soam como brincadeira – é “aquela turma dos post-its”. Afinal, as metodologias tradicionais de gestão de projetos ou de desenvolvimento de software estão aí há décadas, geram uma incrível quantidade de documentação e não deve haver nada mais robusto que isso, não é mesmo? Bem, não é bem assim. Apesar de simples (muitos simples!), as práticas ágeis requerem muita disciplina e processos estruturados para garantir as entregas periódicas. Requerem ainda transparência e muita interação com o cliente, que acaba se envolvendo de tal forma com o método de trabalho e com o produto a ser entregue, que passa a ser o primeiro a defender a equipe de Tecnologia. Ele não é mais aquele “inimigo”, que fica mudando o escopo a cada instante e culpa o desenvolvimento pelo não cumprimento de prazo. A entrega é tão dele quanto de qualquer outro no time e a colaboração flui. Além disso, as mudanças, antes tão indesejadas pela TI e sempre motivo de conflitos, passam a fazer parte do processo de trabalho, direcionando as entregas para o maior valor agregado ao produto final.

Estas mudanças culturais, processuais e de foco não estão limitadas ao ambiente de Tecnologia, ali na ponta, onde o produto ou sistema será desenvolvido. Ao contrário, precisa ocorrer em todo o “value stream”, desde seu início nas definições estratégicas e a escolha correta do portfólio (“o que fazer”). O foco é no valor a ser gerado pelo que se está entregando. Então, entender como captar este valor e medi-lo passa a ser de grande relevância e chave em todo o processo. A entrega (o desenvolvimento) também precisa ser bem feita, é claro!, e é importante ter este fluxo estruturado (o “como fazer”). Mas, a esta altura, o trabalho colaborativo já está estabelecido: uma transformação em todos os níveis, através da criação de uma cultura de participação, autonomia, engajamento, responsabilidade, transparência com muito trabalho em equipe para entrega de valor para o negócio. Simples assim.


  • 0

Gestão do Conhecimento e Lições Aprendidas na Implantação de Scrum

Category : Bússola Digital

Olá,

Tudo bem? Uma dúvida muito comum para quem vai contratar uma consultoria para implantar o Scrum é: “Como fazer a gestão do conhecimento da implantação do Scrum?”

A preocupação é garantir que a equipe interna absorva o conhecimento sobre o método Scrum, para que possa andar sozinha depois.

Saiba neste depoimento de Cláudio Barizon (*) quais foram suas experiências com o tema e as lições aprendidas de sua primeira implantação de Scrum com uma consultoria externa, quando era Gerente de Desenvolvimento de Produtos da Infoglobo:

  • A opção de contratar uma consultoria externa para implantar a metodologia Scrum
  • A escolha de um produto digital como projeto piloto para a implantação
  • A importância da base conceitual teórica do Scrum para o sucesso de uma implantação
  • A gestão do conhecimento na implantação do Scrum
  • Lições aprendidas: o que funcionou bem e o que não funcionou bem
  • A gestão das pessoas na formação de um time Scrum
  • Como o próprio Scrum ajudou na implantação da metodologia ágil

(*) Cláudio Barizon é Diretor de Negócios Digitais da ViaDigital.Solutions e liderou a implantação das metodologias ágeis na TI da Infoglobo

Veja a seguir alguns pontos de destaque:

A opção de contratar uma consultoria externa para implantar a metodologia Scrum: “O consultor Juan Bernabó nos apresentou como faríamos o projeto e nos ajudou muito a entender o novo modelo de atuação: como funcionava, que práticas eram essas.”

A escolha de um produto digital como projeto piloto para a implantação: “Assim que conhecemos o Scrum, para a gente ficou claro que ela seria muito aderente a um produto digital.”

A importância da base conceitual teórica do Scrum para o sucesso de uma implantação: “Na minha humilde opinião, várias das práticas já vinham sendo usadas de maneira instintiva, mas na verdade a gente não tinha a base conceitual correta e foi muito bom entender como funcionava e poder melhorar a forma de aplicar essas práticas.”

A gestão do conhecimento na implantação do Scrum: “Nós tínhamos o interesse de gerar aprendizado para algumas pessoas do nosso time. Então, nós inserimos algumas pessoas da nossa equipe nesse time de projeto (o projeto piloto) para elas absorverem o processo, como que criando um ‘cinturão’ de pessoas nossas ao redor desse time. Isso acabou não funcionando tão bem.”

A gestão das pessoas na formação de um time Scrum: “Tivemos muito atrito, muito calor, muita fricção e um pouco de vaidade porque eram pessoas de times diferentes.”

Lições aprendidas: o que funcionou bem e o que não funcionou bem: “As pessoas podem até ser de equipes diferentes, mas elas precisam se ver e se comportar como um time só. (…) A partir daí, começamos a usar scrum masters internos, porque achamos importante que a pessoa conhecesse os processos internos da empresa.”

Como o próprio Scrum ajudou na implantação da metodologia ágil: “Usamos as próprias práticas do Scrum para avaliar o que estava funcionando e não estava funcionando na implantação do Scrum. O apoio (do consultor) foi fundamental para a gente ter pensado nas perguntas certas e encontrado suas respostas.”

Espero que tenha gostado e que a experiência seja útil, caso esteja pensando em implantar uma metodologia ágil. Por favor, deixe seus comentários abaixo.

Um abraço,

Fabrício Yutaka Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0

Você Sempre Usou Post-it Errado!

Category : Bússola Digital

Duvida? Veja neste vídeo como uma simples mudança na forma de tirar o post-it do bloco faz toda a diferença para a sua durabilidade.


(clique na imagem para assistir)

Fonte: Exame


  • 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


  • 3

Melhorar a performance dos times pode ser mais simples do que parece

Category : Bússola Digital

Olá,

Tudo bem? Hoje trago um vídeo bem interessante. É rápido (menos de 7min) e gera um impacto muito forte na nossa compreensão de performance de equipes, fluxo de trabalho, gargalos e otimização de processos.

Ele compara o tempo de escoamento da água de uma garrafa e mostra como pode cair de 18s para 12s com uma pequena alteração no sistema, sem nenhum componente novo, e como ainda pode diminuir para 4s se for introduzido um simples agente externo.

Clique na imagem para assistir o vídeo:

Tempo gasto para tirar a água da garrafa

Tempo gasto para tirar a água da garrafa (clique aqui para assistir no Youtube)

No primeiro caso, temos muita atividade, mas pouca vazão. O vídeo faz uma analogia com os conflitos corporativos que vemos no dia-a-dia entre diferentes equipes de uma empresa e os processos internos que não geram valor. Pode ser que até exista a otimização local de cada equipe, mas não há o pensamento no todo, de forma conjunta.

Já o segundo exemplo seria para os casos em que há um objetivo comum às equipes e elas perseguem juntas esse objetivo. Isto gera um fluxo contínuo, com todos caminhando no mesmo sentido e regulados pela vazão das entregas.

O que acho bacana neste caso é que não há nenhum novo agente externo. Ainda na analogia corporativa, bastaria que as equipes tivessem um objetivo comum, com metas claramente definidas e convergentes, para que o trabalho e as entregas fluissem melhor.

No último exemplo, houve a introdução de um agente externo e uma evolução mais significativa ainda. A analogia que o vídeo faz é que é possível ter um ambiente corporativo de calma, sem conflitos, estável e também com alta performance de entregas.

E, por que não?, uma cultura genuinamente colaborativa.

Um dos aspectos marcantes nas metodologias ágeis é que elas permitem evoluções como essas na performance dos times. Longe de dizer que tudo funciona às mil maravilhas e perfeitamente, mas é fato que elas viabilizam esse tipo de evolução, porque muitos de seus fundamentos e conceitos são baseados em trabalho colaborativo e na teoria das restrições.

Quem me apresentou este vídeo foi o Jesuino Lopes aqui da ViaDigital.Solutions. Espero que você tenha gostado. Por favor, deixe seus comentários abaixo.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 2

Compartilhando um pouco da Minha Experiência com o Agile: Um Case Especial

Tags :

Category : Bússola Digital

Em 2013, comecei uma jornada nova para mim: saí do mundo corporativo para empreender. Certamente não foi uma decisão fácil, mas aconteceu naturalmente. O Juan Bernabó, mestre e referência na evangelização das práticas pragmáticas, e que foi o nosso consultor na adoção de metodologias ágeis na Infoglobo alguns anos antes, de onde eu vim, buscava um parceiro capaz de realizar as entregas (dos projetos e produtos) e trabalhar na transformação dos ambientes. Nesta ocasião, Jesuíno Lopes e eu embarcamos neste processo (posteriormente, o Fabrício Fujikawa se juntou a nós). Nosso objetivo, à época, foi fazer da Teamware, hoje ViaDigital, uma referência neste trabalho de transição para um modelo de gestão mais moderno, garantindo às empresas (clientes) usufruir dos benefícios das entregas ágeis e da geração de valor cada vez mais rapidamente.

E foi exatamente esta a nossa grande motivação: disseminar esta nossa experiência tão rica e tão transformadora. Na verdade, senti-me na obrigação de compartilhar esta vivência! Mostrar para outras empresas que é possível construir uma área de TI diferente, estratégica, pró-ativa e inovadora, capaz de trabalhar com as áreas de Negócio de forma muito integradas, com total transparência na comunicação e com um objetivo comum. Um verdadeiro trabalho colaborativo, onde a equipe possui mais autonomia e responsabilidade, gerando um profundo engajamento e enorme motivação. E onde busca-se o que é melhor para o produto e para empresa e não para um departamento ou outro: o valor para o negócio é colocado em primeiro lugar, permitindo, assim, que as entregas sejam mais rentáveis e enxutas e, consequentemente, mais rápidas e baratas.

Vamos usar o nosso blog para apresentar cases de como isso é possível e como isso acontece. No entanto, para melhor tangibilizar esta harmonia que contei acima, com o foco no objetivo comum, alegria do trabalho colaborativo e atingimento dos resultados num curto espaço de tempo, geramos um pequeno vídeo. Nele, contamos a experiência que tivemos na entrega de uma nova versão do Site do Globo, enquanto ainda estava na Infoglobo. Foi um momento incrível, com uma tremenda equipe e um super desafio para todos os envolvidos, pois, além do prazo “impossível”, este era um projeto muito importante dentro de um grande programa, onde muitas mudanças estavam acontecendo simultaneamente.


  • 0
Simplificar: menos pode ser mais

Simplificação – A Arte de Maximizar o Trabalho Não Realizado

Olá,

Tudo bem? Li a frase do título deste post no texto 10 Product Owner Questions, que relaciona 10 perguntas importantes para Product Owners. O post sugere que Scrum Masters podem fazer essas perguntas aos POs, como uma forma de coaching.

No final, apresento o link da matéria completa e vou destacar apenas 3 perguntas: as duas primeiras falam sobre características que vemos constantemente nos projetos em que atuamos e a última porque tem a ver com trabalho colaborativo, uma filosofia que acreditamos e pregamos no dia-a-dia.

1) Como você sabe se o seu produto é bem-sucedido e entrega valor?

Sim, é uma pergunta difícil, muito difícil. Por exemplo, tente responder você em relação à última tarefa que estava fazendo. Nada fácil, não é? Daí vem a importância da pergunta: se não sabemos a resposta, de que adianta fazer o produto (ou a tarefa)?

Mesmo que não seja viável medir o sucesso do produto e sua entrega de valor, é importante exercitar este raciocínio. Repare que “não ser viável medir” é diferente de “não ter métricas”.

Por exemplo, para este texto que estou escrevendo, uma possível métrica de sucesso e de entrega de valor poderia ser o percentual de pessoas que refletiram sobre suas próprias atividades, priorizaram algumas e despriorizaram outras, a partir da sua leitura.

É claro que, na prática, medir isso seria muito difícil. Mas, a métrica existe. Percebe a diferença? (E notou que o título do artigo está alinhado com a métrica?)

2) Que funcionalidades devem ser removidas do produto? Como você sabe que elas devem ser removidas? Como você pode afirmar que uma funcionalidade não pode ser removida?

A gente costuma bater muito nesta tecla em relação às histórias do backlog, mas o que achei interessante nesta pergunta foi que ela fala sobre funcionalidades já presentes no produto. Isso mesmo: trabalho já realizado. Por que então gastar mais trabalho para remover um trabalho já desperdiçado?

O autor do texto fala que é importante remover as funcionalidades que tem um ROI negativo, e que entender as funcionalidades realmente essenciais e o quão enxutas elas podem ser, é uma habilidade fundamental para aumentar a agilidade do produto.

Fiquei pensando se a gente fazia isso em nossos próprios projetos. Daí me lembrei de um aplicativo para o qual fomos contratados para fazer a manutenção evolutiva. Recentemente, sugeri remover de uma lista de um filtro de busca cerca de 90% dos seus itens, pois eles resultavam em um resultado vazio quando eram usados como filtro.

Acho que pode ser considerado um caso que se enquadra nesta pergunta: nossa proposta foi a de enxugar uma funcionalidade já existente, removendo opções que, no fundo, não tinham utilidade e prejudicavam a experiência do usuário.

Simplificar: menos pode ser mais

Simplificar: menos pode ser mais (foto: Ana Cotta)

3) Você ficaria tranquilo deixando a equipe de desenvolvimento rodar os próximos dois sprints sem falar com você?

Apesar de parecer o contrário, uma resposta positiva para esta pergunta depende muito de uma cultura de trabalho colaborativo. Quando o PO tira férias, por exemplo, ele tem um substituto que assume bem seu lugar? Se o PO realmente ficar indisponível, a equipe de desenvolvimento consegue falar com outros stakeholders, se necessário?

Para isso, primeiramente, o PO tem que:

  • passar as histórias com um bom nível de detalhes para o time;
  • comunicar a visão e estratégia de produto para todos;
  • deixar o backlog organizado com as próximas histórias razoavelmente detalhadas e priorizadas.

Enfim, o PO tem que fazer adequadamente o seu “dever de casa”, o que é ótimo, porque ele ganha mais tempo livre para focar nas suas outras atividades: estudo de mercado e concorrência, principalmente.

Mas, acima de tudo, as pessoas envolvidas tem que trabalhar colaborativamente pelo objetivo comum e não pensando apenas na sua área de conhecimento ou no seu departamento.

 

Espero que você gostado! Leia aqui a matéria 10 Product Owner Questions e deixe seus comentários abaixo.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


Receba nosso Boletim

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