O Cenário

Para contextualizar um pouco o cenário deste projeto, o squad em que atuei começou a crescer e, tendo maior capacity, o número de demandas também cresceu. Tínhamos os desafios de lidar com o aumento nas informações relativas às demandas dentro do squad com um grande número de membros e aumentar a qualidade das soluções propostas para o sistema. Com estes desafios à frente, uma das decisões foi usar o 7D para melhorar o entendimento do time no processo de refinamento e aumentar o engajamento nas discussões sobre a solução proposta.

Entendendo melhor o problema

O primeiro desafio que encontramos foi fazer com que o Product Owner se preocupasse mais em entender o problema que precisava ser resolvido por cada demanda de trabalho. Para atingir este primeiro objetivo, uma estrutura para entender melhor o problema foi montada para que o PO pudesse seguir e garantir que tinha coletado informações suficientes sobre o que precisava ser desenvolvido e se preocupasse menos na solução do que seria desenvolvido. A partir de um Value Proposition Canvas (em breve teremos um blogpost sobre este método), o PO levava para o time algumas perguntas respondidas, como:

• Para quem? Quais os usuários estão tendo este problema?
• Qual o problema queremos resolver?
• Por quê este problema precisa ser resolvido para este usuário?
• Quais são as dores do usuário em relação a este problema?
• Quais seriam os ganhos que o usuário teria com a solução deste problema?

Abrindo a discussão sobre o solução com o time

Após este mapeamento do problema, o Product Owner trazia as respostas às perguntas anteriores para a reunião de refining e o time entendia melhor sobre a dor que queríamos resolver, a persona que iríamos impactar e o porquê daquela persona estar sentindo aquela dor. O time estressava mais o cenário do problema apresentado para identificar mais personas que sentiam a mesma dor e que solução poderia ser proposta para cada usuário.

Para efeito de exemplificação, vou usar uma história de usuário fictícia onde o problema seria  visualizar uma lista de carros em uma plataforma web.

“Como uma pessoa que quer comprar um carro,

Quero visualizar os carros da Loja X

Para que eu possa escolher um dos carros“

A partir da história exposta, criamos um desenho em um quadro para podermos mapear o problema e a persona relacionada:

Em seguida, o time identifica as soluções aplicáveis para resolver este problema e se há alguma outra persona relacionada a este caso que ainda não foi mapeada. No problema relacionado acima, podemos citar como uma solução a funcionalidade de “Listagem de carros” para o “Usuário da Plataforma”, porém, após algumas discussões, o time identifica que para os dados dos carros estarem disponíveis na plataforma é preciso que alguém cadastre esses dados. No caso do exemplo, precisaríamos de uma pessoa que tenha acesso à lista de carros que a empresa tem em estoque. Vamos chamar esta pessoa de “Gerente de Estoque”. Esta persona precisa de uma funcionalidade de “Cadastrar Carros”, que ainda não existe no sistema, para poder cadastrar os carros.

Esta é uma boa dinâmica para o time como um todo, onde o PO consegue ter uma visão melhor sobre o que o time está desenvolvendo e o time entende melhor o negócio da empresa.

Neste momento, sabemos que temos duas funcionalidades que precisam ser implementadas para resolver o problema do usuário. O time pode priorizar estas funcionalidades, eles podem cortar escopo das funcionalidade para resolver um problema mais urgente e depois evoluir a feature, encontrar outra solução para o mesmo problema, criar um MVP ou uma POC, entre outros. O importante é que eles se alinhem sobre o que vão desenvolver.

Aqui é bom deixar o time discutir e ter alguém para facilitar. O facilitador desta reunião tem sido alguém do time de desenvolvimento escolhido no início da reunião e em cada reunião é alguém diferente, justamente para aumentar aumentar a autonomia do time e tirar a dependência de ter uma pessoa específica para conduzir as cerimônias.

Utilizando o 7D

A partir deste momento o time começa a usar a ferramenta 7D para fazer o refinamento. O 7D é uma ferramenta que consiste em um quadro com 7 colunas que visa cobrir as 7 dimensões de um produto. Esta ferramenta foi fundamental para ajudar o time a pensar com o que eles têm que se preocupar antes de começar a desenvolver uma funcionalidade, e tem sido uma boa ferramenta para disseminar conhecimento e ajudar no ramp-up dos membros do time, tanto do ponto de vista de  negócio quanto técnico.

Basicamente, este método consiste em passar por cada dimensão, discutindo o que é preciso para desenvolver a feature em questão e fazendo relações entre as dimensões.

O quadro do 7D que estamos usando é este mostrado abaixo:

Continuando com o exemplo citado acima, vamos considerar que a funcionalidade “Cadastrar carros” não vai ser implementada e que os dados vão ser inseridos diretamente no banco de dados para que o time possa focar em resolver o problema do usuário “Usuário da Plataforma” com a funcionalidade de “Listagem dos Carros”. A partir desta premissa, vamos começar a montar o quadro.

1 – Colocamos no quadro a funcionalidade que vamos implementar e o usuário para o qual essa funcionalidade vai resolver o problema.

Este mapeamento de para qual usuário a feature vai ser desenvolvida é bem interessante de se usar quando há vários usuário diferentes utilizando a mesma funcionalidade, pois o time consegue desenvolver mais detalhadamente o refinamento das histórias para cada usuário e entender melhor as especificidades de cada usuário.

2 – Colocamos quais ações precisam serem feitas para entregar a funcionalidade para o usuário.

Após colocar no quadro a funcionalidade que vamos refinar e o usuário para o qual queremos resolver o problema, começamos perguntando quais ações precisam ser desenvolvidas para que o usuário consiga utilizar a funcionalidade que estamos discutindo.  Vamos utilizar “1 – Buscar todos os carros do banco de dados” e “2 – Mostrar lista dos carros na tela” para nosso exemplo.

3 – Após listar as ações, listamos quais dados são necessários para que cada uma delas possa ser desenvolvida. Esta etapa é interessante para instigar o time a pensar se há alguma dependência, se precisa acionar alguma pessoa para coletar tal informação (o PO, algum dev de outro sistema que a funcionalidade precisa, o usuário final, etc.) e até mesmo tomar uma decisão do tipo “a pessoa X precisa participar do refining da história Y”.

Para o problema exemplo, podemos colocar “1 – Carros que estejam com o STATUS ‘Para Venda”’ para a ação 1 e “2 – Lista de Carros” para a ação 2.

Depois de levantar os dados que vão ser usados, 4 – levantamos quais seriam as regras de negócio para os dados levantados para cada ação. Nas regras de negócio nós já começamos a definir nossos critérios de aceite para as histórias.

Após mapear as regras de negócio, 5 – levantamos se há algum requisito não funcional ligado a  funcionalidade. Para o exemplo proposto, vamos considerar que a página precisa carregar a listagem em até 2 segundos.

6 – No próximo passo, definimos em qual interface o usuário vai poder utilizar a funcionalidade. Este é um bom ponto também para exercitar o entendimento dos membros sobre como o software está sendo desenvolvido, qual sua arquitetura, com quais sistemas ele faz integração, etc. Para este caso, vamos considerar apenas a página “Comprar Carros” do site.

7 – A última coluna é sobre os ambientes nos quais vamos fornecer a funcionalidade. Esta etapa é bem útil para produtos que são fornecidos em várias plataformas.

Após terminar de preencher o quadro, criamos as histórias baseadas em cada ação ou agrupamos algumas ações em uma única história, caso delas não consigam atingir os requisitos de INVEST.

Estas histórias vão passar por uma etapa de task breakdown, onde o time de desenvolvimento quebra a história em tarefas técnicas, antes de começarem a ser desenvolvidas.

Outro ponto é que, após ter completado o quadro, teremos informações importante, como o contexto da história, que está nas colunas Usuário, Interfaces, Ações, Dados e Ambientes, e os critérios de aceite, que estão nas colunas Regras de Negócios e Qualidade.

Resultados e Conclusões

Com o uso da ferramenta apresentada, conseguimos melhorar alguns pontos no dia a dia do time:

• Conseguimos trazer de maneira mais clara e com informações suficiente as dores dos usuários e, consequentemente, começamos a desenvolver melhores soluções para os usuários.
• Melhoramos o entendimento do time como um todo sobre os usuários: quem são, quais as suas dores e como entregamos valor para eles.
• O time conseguiu compartilhar melhor o entendimento sobre a solução que está sendo desenvolvida e também acelerou o ramp-up dos desenvolvedores.
• Diminuiu o tempo que as histórias ficavam nas etapas de Testes e Validação e melhorou a qualidade do produto entregue, pois o time estava desenvolvendo as histórias de forma mais aderente às necessidades dos usuários.
• O Definition of Ready, que é a definição do que uma história precisa ter antes de entrar no fluxo de desenvolvimento, foi melhorado com esta ferramenta, com melhores critérios de aceite e um mapeamento maior sobre o que precisa ser desenvolvido.
• O time ficou mais engajado em construir a solução após as discussões geradas para propor soluções.
• Eles também começaram a questionar mais sobre a solução e resolver melhor os impedimentos do time, dado que tinham mais informações nas mãos e se sentiam mais responsáveis da solução proposta.

Aproveitando que estamos falando sobre o refinamento e melhorias dessa cerimônia, deixo aqui a recomendação de posts sobre refinamento, escrito aqui na Plataformatec: A importância do processo de refining em um projeto e O que aprendi sobre o Refining de User Stories em projetos.

E você? Já teve dificuldades no processo de refinamento? Já usou alguma ferramenta interessante para essa cerimônia? Deixe seus comentários abaixo sobre sua experiência com refinamento!

The post Melhorando o refinamento e a autonomia de times com a implementação do 7D first appeared on Plataformatec Blog.

Vamos falar sobre Story Mapping!

Você que já participou de uma equipe de desenvolvimento de software, provavelmente já se deparou com as dificuldades enfrentadas por profissionais de produto para priorizar o backlog e definir releases. Essas tarefas podem se tornar ainda mais difíceis sem as ferramentas e técnicas ideais, distanciando os releases dos principais objetivos do projeto e criando features desnecessárias para o produto.

Para ajudar a resolver esses problemas, vamos detalhar neste blog post o uso do Story Mapping, conhecido para alguns e um grande mistério para outros. Essa ferramenta foi criada por Jeff Patton e descrita mais profundamente no livro  “User Story Mapping”, do mesmo autor.

Num primeiro momento, pelo nome, você deve estar pensando que serve apenas para mapear itens de trabalho. E se eu disser que com o uso do Story Mapping você pode ainda potencializar a entrega de valor de cada release, alinhar expectativas de entrega entre stakeholders e despriorizar tudo aquilo que não se faz essencial para a entrega? O Story Mapping não vai salvar e resolver todos os problemas do seu projeto, mas vai ser muito útil especialmente em dois momentos: no início do projeto, quando está se criando um produto e não se tem uma direção para seguir, ou após uma mudança de objetivo que altere todo o escopo planejado.

PASSO 1 – Montagem do Fluxo de Valor

Para iniciarmos o Story Mapping, primeiramente precisamos ter um fluxo de uso ou uma Big Story que vai narrar a interação do usuário com o produto , levando em conta o caminho que o usuário percorre para atingir o objetivo que esse produto se propõe a resolver. Essa será a linha de base para o Story Mapping.

Caso ainda não tenha esse fluxo, ele pode ser montado em uma dinâmica com os donos do produto e o time envolvido na criação do mesmo, expondo suas visões do que seria ideal o produto realizar. Geralmente utilizamos o fluxo de valor ou o principal artefato (objeto principal do produto) para nortear a discussão.

PASSO 2 – Mapear histórias

A segunda etapa é o momento de analisar o fluxo, identificando etapas que tenham o mesmo contexto ou que sejam originadas de uma mesma ação do usuário, gerando assim os principais épicos, que servirão de base para o levantamento dos itens de trabalho. Os épicos servirão como um backbone (coluna vertebral) do story mapping.

Chegou então a hora de detalharmos o que precisa ser feito dentro de cada épico. Essas serão as histórias de usuário (ou itens de trabalho, se preferir chamar assim) que serão desenvolvidas. Deixo claro aqui que essas histórias ainda passarão por refinamento, que é o momento que, de fato, vamos discutir a fundo os detalhes da tarefa e remover maiores incertezas técnicas e de negócio. O objetivo aqui é apenas mapear os itens de trabalho, e não detalhar e escrevê-los. No exemplo da imagem abaixo ainda temos os temas, sendo este um agrupamento lógico de épicos com o mesmo contexto dentro do sistema.

Antes de falar do próximo passo, uma dica: tenha objetivos claros, priorizados e factíveis sobre o projeto, para que se possa definir os releases com maior entrega de valor. Quando se planeja um produto, geralmente se tem um objetivo a ser atingido e se espera que ele agregue um valor estimável ao negócio. Caso os objetivos estejam genéricos ou amplos demais, recomendo que este objetivo seja fatiado em partes menores que poderão se tornar outros milestones de entregas do produto. Por exemplo, você pode ter um MVP (Minimum Viable Product), do seu produto. Esse primeiro release poderá entregar valor para o negócio mais rapidamente e, mesmo que seja feito de forma mais simples, vai permitir a coleta de métricas de produto, validar hipóteses sobre o que está sendo feito e aumentar a entrega de valor de releases futuros.

PASSO 3 – Definição dos Releases

O terceiro e último passo é, após ter os principais objetivos mapeados e priorizados, fazer a distribuição dos itens de trabalho da etapa anterior entre esses objetivos. Uma boa maneira de fazer isso é traçar raias no seu board de Story Mapping, onde cada raia representa um objetivo e, assim, facilitar a distribuição dos cards. Veja o exemplo abaixo:

Se fatiamos o backlog, nas fatias horizontais teremos os objetivos e as histórias, enquanto na vertical teremos os épicos com suas respectivas histórias. Durante a distribuição de histórias e objetivos, ou até mesmo durante o desenvolvimento do produto, certamente irão aparecer outros itens que antes não haviam sido mapeados, mas o escopo estará bem mais detalhado e direcionado para o que precisa ser feito após as discussões.

Com a participação de todos os stakeholders na dinâmica para definições de fluxo, épicos, histórias e releases, ganhamos em alinhamento de expectativas sobre as entregas, definição de um MVP que faça sentido para o negócio e um direcionamento das próximas etapas do projeto.

Para dar continuidade ao tema de priorização de backlog e definição de releases valiosos para o negócio, deixo aqui a recomendação de um post sobre métricas de produtos, escrito aqui na Plataformatec: O que seriam boas métricas para produtos digitais?

E você? Já tem a visão do backlog e releases do seu projeto? Deixe seus comentários abaixo sobre sua experiência com o Story Mapping!

The post Vamos falar sobre Story Mapping first appeared on Plataformatec Blog.

Responsabilidades como alocação de equipes, controle de recursos financeiros, desenvolvimento de cronogramas e elaboração de enormes Planos de Projetos passaram a ser responsabilidades de outros papéis.

Alavancado pelo uso das metodologias ágeis, o conceito de gestão distribuída tem levado uma nova característica aos times: mais autonomia para tomar decisões de negócio, cuja participação do time no direcionamento de um produto tem sido essencial para que a mudança constante, inerente desse ambiente, tenha menor impacto sobre a qualidade do projeto.

Então, eu lhe pergunto: com o empoderamento dos times nas organizações, onde foi parar o Gerente de Projetos com perfil “manda-chuva”? Para ficar mais claro o que quero dizer com esse termo, imagine o tradicional gestor de uma estrutura funcional e hierarquizada, onde funcionários, coordenadores, gerentes, diretores e presidente se baseiam no conceito comando-controle e estes respondem diretamente ao seu gerente funcional.

Diagrama representando uma estrutura funcional

O dinamismo, a necessidade de adaptação rápida e resposta às mudanças, embasadas pelo modelo de gestão ágil, fez com que os profissionais da antiga estrutura funcional se adequassem aos times multidisciplinares focados na entrega de valor, que saibam responder imediatamente à imprevisibilidade deste ambiente e que se adaptem constantemente a novos contextos.

O papel do tradicional Gerente de Projetos pode ser comparado ao papel exigido pela necessidade requerida nesse novo ambiente: o Gerente de Produto, Product Manager, ou qualquer nome da moda que se dê ao cargo do responsável pela evolução do produto. Limito-me aqui a chamar de Gerente de Produtos. O que faz esse tal Gerente de Produtos então, se não cobrar e exigir produtividade?

O Gerente de Produtos deve ter como objetivo ser a sustentação e prover o suporte necessário ao time de desenvolvimento. Se o time tem que ser capaz de tomar as decisões e se auto-organizar para desenvolver e entregar o máximo de valor nas entregas ao cliente, o Gerente de Produtos deve ser o canal de comunicação entre o time e os interessados pelo projeto (stakeholders), definir os objetivos e visão estratégica, construir um roadmap sólido dos entregáveis, priorizar as demandas e intermediar a integração e o entendimento das principais áreas de desenvolvimento de um produto: UX, Business e Tecnologia.

Papel de um gerente de produto

Diferentemente do tradicional Gerente de Projetos, o Gerente de Produtos deve focar no “o que deve ser feito” e menos em “como deve ser feito“, sendo essa responsabilidade compartilhada com o time, o que inclui definir processo de desenvolvimento, remover impedimentos, tomar decisões sobre mudança de escopo e detalhar requisitos das tarefas. Os times que antes eram considerados times de desenvolvedores, passaram a ser times de produto com membros multidisciplinares, responsáveis por validar, testar e desenvolvê-lo, como uma “mini-startup”.

Assumindo este como sendo o rumo que o papel do Gerente de Projetos tem tomado, é fato que o engajamento e a participação do time têm se tornado cada vez mais importante, o que mostra também o quanto os princípios ágeis têm influenciado na transformação desse papel nas empresas que trabalham com desenvolvimento de software.  

Para aprofundar um pouco mais nesse assunto, recomendo dois blogposts que foram escritos aqui na Plataformatec sobre definição de objetivos e priorização de features e projeção de entregas.

The post Onde foi parar o Gerente de Projetos? first appeared on Plataformatec Blog.

A expressão foi utilizada para referenciar a fábula “A Lebre e a Tartaruga”. Na história, uma tartaruga vence a corrida contra uma lebre muito mais rápida. A lebre, confiante da vitória, acabou parando para uma soneca.

Há uma série de morais ligadas a esta fábula, e a que Reinertsen nos traz é: eliminar períodos de inatividade pode trazer mais resultados para o processo do que acelerar as atividades que já fazem parte dele.

“Inatividade” refere-se ao tempo que uma demanda fica em uma fila até que alguém volte a trabalhar nela. Exemplo: uma user story aguardando para ser testada. —  Não confundir com a inatividade de um membro da equipe tirando uma soneca no meio da tarde, assim como a lebre :D.

No Sistema Toyota de Produção, uma das bases para o Lean Manufacturing, Taiichi Ohno propôs que tudo que não agrega valor ao cliente é desperdício e identificou sete principais causas de desperdício na manufatura, entre elas, espera em filas e estoques.

No livro “Lean Software Development“, Mary e Tom Poppendieck, adaptaram os sete desperdícios para o contexto de desenvolvimento de produtos de software e, novamente, estava lá: espera em filas e trabalho parcialmente feito (uma demanda que já teve esforço, por exemplo, de design e ainda não foi desenvolvida), um paralelo com os estoques da manufatura.

Don Reinertsen é mais enfático: filas são as maiores causadoras de processos com baixa performance. Para ele, as filas:

• aumentam lead time, custos do processo, variabilidade e riscos;
• reduzem eficiência do processo, motivação da equipe e tornam o feedback mais lento, o que compromete a qualidade e propicia bugs.

Com tantas evidências, o que você pode fazer para minimizar os efeitos das filas no processo? A minha dica é: acompanhe e controle o tamanho das filas em seu fluxo de trabalho.

Se você não tem visibilidade das filas no seu workflow, crie etapas intermediárias. Por exemplo, adicione uma etapa entre “desenvolvimento” e “testes” para acomodar as demandas que já foram desenvolvidas e estão aguardando para serem testadas. Assim, fica evidente as demandas em progresso e as que estão paradas, facilitando a identificação de gargalos.

Após isso, acompanhe suas filas pelos gráficos Cumulative Flow Diagram e Lead Time Breakdown. O gráfico CFD permite que você identifique gargalos e aumento no tamanho das filas; com LT Breakdown você identifica demandas há muito tempo em uma fila ou bloqueadas.

Por fim, definir limites de trabalho em progresso (WIP) para cada uma das etapas do seu fluxo, incluindo as filas. Dessa forma, evita-se que demandas sejam iniciadas antes que o trabalho em progresso seja finalizado, sobrecarregando ainda mais o sistema, especialmente, as filas.

Este texto também faz parte da ContÁgil, nossa newsletter mensal com curadoria de conteúdo pela equipe da Plataformatec sobre gerenciamento de projetos, metodologias e cultura ágil. Se você ainda não é assinante, assine agora! 

The post Um mal invisível: filas e seus impactos no processo first appeared on Plataformatec Blog.

Estamos acostumados a sempre discutir e debater sobre como as coisas são ou como elas deveriam ser no nosso ambiente de trabalho, com o uso da filosofia trazemos essa discussão sobre o que fazer ou como conduzir nossas ações e suas ambiguidades, dado que o mundo é do jeito que ele é. O que fazemos em nossos projetos profissionais, e as decisões que tomamos no nosso dia-a-dia, acabam se inserindo nesse contexto de uma forma ou outra. O objetivo desse post é fomentar uma ruptura nas certezas e verdades estabelecidas dentro de todo conhecimento criado em torno da “Agilidade”. O artefato central dessa discussão é o conhecimento, a forma como interagimos com ele e a forma como usamos ele (ou ele nos usa?). Não vejo forma melhor de começar essa série de provocações senão definindo o que é conhecimento para mim:

| Conhecimento é uma crença justificável.

Ou seja, perspectiva e conhecimento estão diretamente relacionados! Uma “coisa” serve como conhecimento até que acreditemos que outra “coisa” possua justificativas que superem as anteriores. Se observarmos uma empresa como uma organização que produz conhecimento, é possível concluir que o ponto de vista do indivíduo que lida apenas com uma parte da realidade não é o suficiente. O conhecimento não é apenas parte da realidade. É a realidade, mas vista a partir de um determinado ângulo. A mesma realidade pode ser vista diferentemente, dependendo do ângulo (contexto/circunstâncias) do qual se vê.

“Na criação do conhecimento, não se pode ser livre do seu próprio conceito. — Nonaka & Takeuchi”

Os contextos econômico, cultural e histórico são importantes para os indivíduos que produzem conhecimento. Esses contextos permitem a interpretação da informação e a criação do significado que se deseja transmitir. É por isso que a externalização do conhecimento pessoal pode levar a falsidades ontológicas e falácias (Spotify model, SAFe, story points, Scrum…), pois a complexidade total de um determinado fenômeno pode permanecer oculta. Por isso, quando criamos conhecimento é importantíssimo ver todo o quadro da realidade (perspectiva) interagindo com outros que a vejam a partir de outros ângulos, isto é, compartilhando seus conceitos! E a partir desses conceitos é que podemos julgar se o conhecimento a ser transmitido é útil ou não ao nosso contexto atual.

Há quem acredite em certezas imediatas, tais como: scrum é ágil, SAFe é a melhor opção para escalar agilidade, estimativas são imprescindíveis sem nem procurar os conceitos por trás. Me perguntei: o que leva essas pessoas a se tornarem ferramentas do conhecimento ao invés de usar o conhecimento como ferramenta? Elas acham que usam o conhecimento, mas na verdade o conhecimento as usa.

O poder das Ideias de Massa

Acredito que o problema principal são as causas que normalmente vem acompanhadas dessas ideias, causas onde os gestores têm onde se agarrar, causas que sempre vem acompanhadas de um grande vislumbramento de como a organização poderia/deveria ser melhor (ideologia). O ponto é sempre colocar as ideias a seu serviço, você será pragmático quando isso lhe for útil. Isso significa que você entende que todas as ideias podem ser úteis se usadas de forma puxada pela situação/contexto. É diferente de tentar impô-las como verdade para todos os contextos existentes/inexistentes como se fossem coisas sempre iguais (outra certeza imediata que consultorias de grande porte vendem). O perigo de se identificar com a ideia é se tornar viabilizador e propagador dela (a ideia te usa), ao invés de beneficiário de sua efetividade perante o contexto/problema que você vive hoje.

“The issue is one of defining your identity by membership of a social group rather than simply a tool user. For example, you could use Pragmatic philosophy without identifying yourself as a Pragmatist. The important thing is not to let an idea, concept, tool or technology define you. A software engineer who uses Java is okay. A Java Developer is not okay. — David J Anderson”

Complexity

Isso tudo na prática

Como o gestor pragmático pode voltar a conhecer, a criar princípios? Só há um meio: experimentando! Os caminhos que levam para cima são sempre diferentes, já os caminhos que levam para baixo, são sempre os mesmos. Fazer do seu projeto um experimento é a única forma de criar conhecimento com real valor para a sua organização. Admitindo que não existem contextos iguais, partimos da premissa de que todo o conhecimento produzido e acumulado sobre gestão, do qual temos acesso, não nos dá nenhuma certeza imediata quanto a efetividade.

Exemplo: muito se discute sobre a dualidade Eficiência x Eficácia, em qual investir primeiro? Qual priorizar dado o meu contexto? O que o framework XPTO fala sobre isso? E se eu te dissesse que os dois são uma única coisa? Faz parte do senso comum achar que quando estamos criando ideias (upstream) a eficácia predomine, pois não queremos cometer o erro de construir a coisa errada, e na construção (downstream) a eficiência é mais importante para fazer as coisas de forma rápida. Porém se nos colocarmos além dessa dualidade é possível enxergar um outro ângulo: focando eficácia apenas no upstream (opções de ideias) temos o risco de ocorrer starvation no downstream (solicitações de execução), sem eficácia no downstream é necessário confiar cegamente no upstream para que seja eliminado os riscos de demandas que não entreguem valor entrarem no fluxo. No final das contas a realidade é bem mais complexa do que estamos acostumados a categorizar (pensamento cartesiano do século XVIII) e arquivar como “certezas” em nossas mentes.

Toda essa teoria pós-moderna de criação do conhecimento organizacional que foi apresentada aqui, pode ser estudada com mais aprofundamento técnico na obra Gestão do Conhecimento publicada por Hirotaka Takeuchi e Ikujiro Nonaka. A definição ocidental mais comum sobre o que é conhecimento enfoca a “veracidade” (conhecimento das coisas em si) como atributo essencial para a construção do conhecimento, ou seja, esperam que a verdade seja sempre limpinha. Aqui alimento a natureza do conhecimento como “crença justificada” onde a perspectiva tem mais valor do que a “veracidade”, isso serve como um convite para uma grande pluralidade de ideias e experimentos que ainda estão por acontecer, essa experimentação permitirá uma gama completamente nova de conhecimentos, mais audazes, mais genuínos!

E você? Como tem sido sua relação com o conhecimento?

The post O Agilista e o Martelo first appeared on Plataformatec Blog.

Veja aqui quais foram as respostas:

Daniel Mello 

Sempre existe a tendência de que as novas metodologias apareçam como resposta a ponto fraco notório do status quo. Como nota-se que a abordagem Agile está sofrendo com questões de escalabilidade, então a próxima onda metodológica deverá atacar a gestão de projetos dentro de uma visão mais corporativa e de negócios, principalmente porque não é mais possível tratar o desenvolvimento de software como processo estanque ao restante da organização. Também percebo uma tendência na evolução das plataformas de gestão, sendo que qualquer tecnologia disruptiva que afetar os negócios afetará também a gestão de projetos de software. Isto posto, minhas apostas são na consolidação de abordagens de transformação digital, transformação ágil e ágil em escala, assim como no uso de tecnologias como blockchain e deep learning como bases para plataformas de gestão de projetos.

Guilherme Fré

Em minha opinião, o futuro da gestão de projetos tende a ser cada vez mais “agnóstico” com relação a frameworks e metodologias, e cada vez menos uma busca por “balas de prata”. Neste cenário, o principal desafio de agilistas e gerentes de projeto será compreender os contextos em que estarão inseridos, de maneira que consigam selecionar as práticas mais adequadas às suas necessidades dentre aquelas propostas por frameworks e metodologias existentes, propor adaptações sempre que necessário e fomentar uma cultura de aprendizado, adaptação e melhoria contínua, que é base da mentalidade ágil.

Raphael Albino

Acredito que a base da gestão de projetos que envolve prazo, custo, escopo, qualidade, riscos, expectativas e pessoas, não mudará. Os clientes continuarão buscando obter produtos de qualidade, com um baixo grau de risco e em um determinado momento do tempo. Dados históricos e técnicas analíticas serão importantes para a projeção dos prazos de entrega. Gerenciar os anseios dos indivíduos, saber utilizar os meios de comunicação digitais para transmitir mensagens claras e conhecer as habilidades e competências dos indivíduos serão disciplinas fundamentais para uma gestão efetiva de projetos. Além disso, vejo que uma discussão que será importante para os próximos anos estará em torno dos resultados alcançados através do produto dos projetos e para isso penso que as organizações trabalharão cada vez mais com iniciativas pequenas e que possam ser testadas o mais rápido possível.

Lucas Colucci

Com a intensificação do uso de dados massivos para tomadas de decisão (Big Data, Machine Learning e etc), e a automatização da coleta e análise de métricas de processo, o papel de um gerente de projetos (Agile Coach) pode ficar bem diferente. As ferramentas para facilitar a nossa vida podem ficar mais robustas, mas ainda precisaremos entender como elas funcionam e como modelar nossos problemas para aproveitar todo o potencial que elas podem trazer. Portanto, acredito que cada vez mais os GPs/ACs precisarão entender de estatística e leitura de fluxo para se diferenciar no mercado e conseguir tomar melhores decisões.

Henrique Oliveira

Nos últimos anos, o mercado tem demonstrado muito dinamismo. O que era considerado correto passa a ser questionado e, com isso, novas abordagens surgem para suprir as novas necessidades e demandas das organizações. Os próximos cinco anos serão desafiadores, visto que, atualmente, projetos envolvendo Inteligência Artificial, Machine Learning e Transformação Digital estão criando raízes nas empresas e, por isso, novos desafios e métodos de trabalho surgirão para que esses projetos terminem com sucesso. A dica de ouro é: mantenha-se atualizado, não se apegue a um método de trabalho e sempre pense em inovação!

Felipe Gimenes

Se olharmos de forma mais ampla, a evolução dos métodos ágil ofereceu maior autonomia a cada membro dos times, diminuindo assim, a dependência entre eles. Portanto, dado o contexto do ambiente de TI, a tendência são as equipes ágeis trabalharem cada vez mais de forma remota, aumentando a necessidade por ferramentas e técnicas que possam garantir a qualidade do processo e mitigar os riscos de comunicação.

Luiz Bernardo

Com a onda de transformação digital, acredito que teremos dois grupos de organizações daqui a um tempo: um em que aplicaram ferramentas/metodologias/soluções “bala de prata”, acabaram não tendo todos os resultados desejados e terão resistência a fazer novas tentativas, assumindo que o ágil em si fracassou; e outro grupo em que focou mais nos resultados obtidos, usando soluções de maneira mais pragmática focando nos problemas. Os agilistas devem se atentar mais aos resultados, diversificar seu ferramental e acrescentar “hard skills” às suas habilidades para ir de encontro às ansiedades da sua organização.

Wesley Zapellini

Em cinco anos estaremos lidando com o resultado das transformações digitais (as de sucesso e as nem tanto). Contextos em que frameworks de escala como SaFE, LeSS e DaD foram adotados e necessitam de ajustes para que façam sentido ao propósito das organizações.
Minha dica para este futuro é conhecer as virtudes e fraquezas destes modelos e despir-se da preferência pessoal para que o foco seja resolver problemas em vez de aplicar métodos.

Nossa equipe de agile, da esquerda para a direita: Daniel Mello, Wesley Zapellini, Luiz Bernardo, Guilherme Fré, Lucas Colucci, Raphael Albino, Henrique Oliveira e Felipe Gimenes

Essas foram as respostas dos consultores. E você? Qual é sua opinião sobre o tema? Compartilhe conosco nos comentários!

The post ContÁgil – Edição de Aniversário first appeared on Plataformatec Blog.