Uncategorized

Este artigo foi escrito por Eduardo Diederichsen, Felipe Lindenmeyer  e eu. Eduardo e eu somos líderes da área de desenvolvimento de software na ilegra, e Felipe é um account manager sênior. Todos estamos conectados diretamente às exigências de clientes.

Diariamente negociamos com muitos clientes. A parte mais difícil não é dá-los um preço ou conduzir uma apresentação com slides bonitos e muitas buzz words. A parte mais difícil é identificar se o cliente potencial possui um desafio real e como este desafio pode ser abordado pelo potencial, linguagem e visão de mercado de nossa companhia. Quando descobrimos, o cliente merecerá nosso mais profundo foco para termos um bom entendimento e oferecer algo que se encaixe perfeitamente a suas necessidades, mesmo que ele ainda não entenda isto, e então tentar ajudá-lo a entender.

A experiência

Mas o que faz a experiência ser tão perfeita quanto deve ser para que o cliente assine o novo contrato? Impossível dizer pois que compra qualquer coisa são pessoas. Pessoas se baseiam em coisas diferentes para avaliar suas experiências em todos os lugares, dando mais peso a diferentes pontos baseado na sua personalidade e nas influências que receberam durante toda sua vida.

O cenário 

Este recente novo cliente executou uma jornada completa, desde o contato mais inicial até a assinatura de contrato toda dirigia por eles junto de vários candidatos. No final do processo eles decidiram comprar de nós. Vou relatar o que foi feito e como as coisas poderiam ter acontecido de forma diferente.

O cenário do cliente

É um cliente da área financeira, então ele sabe que os clientes financeiros no Brasil são muito exigentes com relação a toda a UX e a flexibilidade dos produtos. Na área financeira, o Brasil é o país com a User eXperience mais desenvolvida em todo o mundo, então a competição e os investimentos por aqui são grandes.

Primeiros contatos

O que aconteceu: o primeiro contato aconteceu em uma celebração casual não relacionada a trabalho. O assunto no grupo se dirigiu a trabalho. Exploramos rapidamente alguns exemplos de como temos ajudado alguns importantes parceiros a estarem a frente de seus competidores. O que realmente aconteceu: a atenção foi pega e cartões foram trocados. Poucos dias após uma reunião foi solicitada a nós para falar sobre nosso portfolio e conhecer seus requerimentos e preocupações.

A reunião

O que aconteceu: aconteceu na sede do cliente. O objetivo era, como solicitado, falar um pouco sobre cenários em que temos trabalhado e as oportunidades que temos identificado e previsto como experts no mercado. O que realmente aconteceu: eles entenderam que tínhamos conhecimento para ser um bom parceiro, e que se contassem conosco teriam opiniões de especialistas no mercado. Então o próximo passo é enviar uma proposta e todos comemoram? Sim, mas não tão rápido.

Os desafios

• Primeiro! O que aconteceu: este cliente é uma empresa brasileira muito conservadora que ainda não tomou iniciativas relacionadas a transformação digital e nem mesmo quer isto. Já nós estamos muito acostumados a trabalhar baseado em metodologias ágeis, abordagens Lean, testar e descartar perdas rapidamente, etc. Eles queriam que tudo fosse previsível com objetivos e passos definidos. O que realmente aconteceu: eles entenderam que seus concorrentes já não trabalham mais neste modelo e que se mantivessem aquela forma, se manteriam atrás no cenário de competição. Então formulamos um misto de práticas que dariam parte dos controles que eles estavam solicitando mas ao mesmo tempo deram partes da liberdade que este tipo de trabalho necessita.
• Segundo! O que aconteceu: eles nos disseram que gostariam de estar a frente de seus concorrentes sabendo quanto isto custaria e quanto tempo tomaria. Bem… se nós tivéssemos estas respostas, nós seríamos um dos competidores. E é neste ponto em que o mindset Lean e de experimentação recebem atenção. As startups que estão incomodando gigantes da indústria não têm este tipo de respostas. O que realmente aconteceu: decidimos atacar um primeiro entregável (podemos chamar de MVP) e depois disso realizar uma nova avaliação para desenhar próximos passos.

Quando as coisas esfriaram

O que aconteceu: tivemos os passos acima, mas estava tomando muito tempo para uma decisão ser feita e as coisas esfriaram (más notícias). Nossa decisão foi de convidá-los para vir à nossa empresa para que pudessem ver com seus próprios olhos tudo que discutimos. Eles realmente se impressionaram com nosso escritório pois viram que é desenhado da forma que precisa ser para dar liberdade às pessoas pensarem e inovarem. Este foi um passo chave porque puderam falar com pessoas que realmente trabalhariam em seu projeto. O que realmente acontece: a negociação esquentou novamente.

O que será encarado de forma diferente por cada pessoa

Há muitas questões subjetivas na explicação das frases acima. Nelas não exploro linguagem corporal. Não estou explorando frases que dissemos uns aos outros e como nos portávamos durante as reuniões. Logo, não estou dizendo como a empatia foi criada aqui. Vamos dar uma olhada mais próxima.

O cenário do cliente

Algumas empresas podem ter receio de inovar. É um cenário completamente novo. Pessoas temem o que não conhecem. Elas não sabem o que está vindo, então ficam com medo e param. Para outras companhias, o desconhecido é entusiasmante e elas sabem que é do desconhecido que a inovação virá. Elas procurarão por isso rotineiramente.

Primeiros contatos

Uma vez que aconteceu em um evento social, o foco não era uma avaliação. A empatia veio facilmente pois falamos de nossos cases brevemente (sem mover o foco de toda a noite para trabalho somente) e humildemente. Se fossemos muito sedentos pelas suas necessidades, poderíamos ter transformado o momento em momento chato e perder a atenção conquistada.

A reunião

O objetivo da reunião foi mostrar nossas capacidades e também flexibilidade para entender as preocupações sobre modelos e o que estávamos propondo. Naquela hora nós investimos tempo explicando e desmistificando práticas de desenvolvimento de software como Dojos, Meetups, modelos de gerenciamento de times, nossas preocupações com relação a qualidade (Testes A/B, testes de caos, etc). E naquela hora um fato muito importante aconteceu: a empatia com um dos participantes foi tão grande, ele viu tanto valor na proposição, que começou a defender algumas das abordagens sugeridas aos sponsors do projeto de forma muito entusiasmada.

Os problemas

Tivemos de usar muito conhecimento para mostrá-los as diferenças entre a forma que estavam tentando abordar o problema e a direção que vemos que o mercado está tomando. Foi um trabalho duro entender como ele estão acostumados a tratar projetos e misturar a uma realidade que pudéssemos trabalhar de forma a ter certeza de que alcançaríamos os resultados que ambos estávamos buscando naquela parceria. Mas o maior passo alcançado foi o uso do mindset de experimentação para abordarmos a primeira fase. Eles optaram por dar um tiro inicial no modelo que foi sugerido. Esta é a chance de manter as coisas andando bem para construirmos ainda mais confiança.

Quando as coisas esfriaram

Esta foi a parte perigosa. Ligar e incomodar a paciência do cliente não teria sido uma abordagem eficiente. Trazê-los a um ambiente conhecido onde poderíamos falar novamente sobre alguns assuntos e remover as dúvidas e objeções restantes foi uma boa iniciativa. As pessoas não entenderão tudo na primeira vez que você falar ou apresentar algo. Você precisará repetir no momento perfeito em que sua explicação fará sentido a eles para ter sua atenção e interesse afetados.

Apenas mais alguns exemplos genéricos

Um cliente pode gostar de escutar mais buzz words todas pronunciadas em inglês. Outro cliente, vindo do interior, pode não gostar pois considera que isto só funciona em grandes companhias. Sobre a proposta: um cliente pode preferir um documento repleto de belas imagens explicando de forma mais abstrata o que será alcançado. Outro pode preferir receber um documento de somente uma página indo direto ao assunto com relação aos entregáveis, usando somente texto. É imprevisível.

Legal! Como posso aprender com este cenário? 

A boa CX (Customer eXperience) se torna mais desafiadora de atingir quando falamos de ofertas B2B ou B2B2C. Quando você tem um cenário B2C você provavelmente terá pessoas no fim do processo que você deve agradar com sua oferta e vantagens. É mais fácil perguntar: “hey, você gostou desta nova feature?”. Voltando ao B2B ou B2B2C as variáveis são incontáveis, uma vez que você precisará lidar com muitas pessoas desde o início da negociação até alcançar o fim do contrato.

Como atacar de forma eficiente?

Resposta rápida: esteja interessado. Resposta longa: Mantenha o conhecimento entre as pessoas envolvidas, use esta experiência, e esteja interessado sobre evoluir o processo e realmente aprender com as lições aprendidas. Tente entender linguagem corporal e psicologia, conheça mesmo quem está comprando de você. Esta pessoa escreve publicamente? Dá discursos? O que ele está falando/escrevendo/lendo/escutando/estudando que você pode levar em consideração para criar um momento para um contato rápido?

Atualmente quando falamos de negócios, empresas, dinheiro, processos, e tudo mais, sempre nos voltamos a inovação. Melhorar processo interno? Inovação. Fazer um novo software para encurtar ou automatizar trabalhos? Inovação. Ganhar mais dinheiro ou gastar menos dinheiro? Inovação.

Todas as áreas de conhecimento falam em inovação. Cientistas procuram inovar sempre para obter novas fórmulas, teorias e avanços. Banqueiros inovam para obter margens maiores de lucro. Arquitetos inovam em construções para encontrar materiais mais baratos e mais resistentes. Desenvolvedores e profissionais de TI inovam para fazer sistemas mais rápidos e que tornem a experiência de seus usuários cada vez mais imersiva.

Uma vez que todas as áreas precisam inovar, o que as empresas novas e tradicionais fazem para que isto seja possível? Como estimular um ambiente inovador? Que resultados esperar de quais tipos de inovação?

Quebrar hierarquia

A hierarquia mata a inovação. Encare isto. A pessoa que está propondo a inovação não pode depender do julgamento de outras 4 ou 5 acima de seu nível hierarquico até que a ideia chegue a quem realmente a entenderá.

As inovações incrementais mais bem sucedidas e mais rápidas são aquelas que pesquisam o hábito do consumidor. É uma inovação rápida, está na boca de todos os usuários que usam sua ferramenta. É só perguntar. Ela não pode esperar pela hierarquia.

As pessoas têm medo de levar suas ideias adiante por acharem que serão julgadas. Têm medo de se sentirem diminuídas caso sua ideia não seja boa. Quando há muitas etapas a serem vencidas, a ideia morrerá sem chegar aos ouvidos de quem realmente importa. Com isso, vamos ao próximo ponto…

Tenha muitos ouvidos

Vejo muitos clientes se orgulharem e dizerem: “criamos uma área de inovação!”, com orçamentos volumosos! Já vi a “Área de inovação” ser o novo nome do R&D (ou P&D – Pesquisa e Desenvolvimento). Reconheço que a inovação precisa começar de alguma forma, mas restringir os ouvidos somente às vozes vindas da área de inovação é perigoso. É um passo sim, mas somente isso. Se esta é a forma de iniciar, comece por aqui!

Mas lembre que empresas pequenas e com poucos funcionários não possuem áreas de inovação:

• O Nubank tem um departamento que se chama “fator Wow!”. Como o nome sugere, a responsabilidade do time é criar experiências que impressionem seu cliente. Mas a inovação deles não surge somente no departamento “fator Wow!”.
• Seu cenário é de empresa grande? Pense no Google. Com milhares de funcionários, 20% do tempo de cada funcionário é livre para trabalharem em suas próprias ideias.
• O modelo de negócios da Google permite este tempo ocioso pois sua fábrica de dinheiro está automatizada? Legal, vamos olhar para a Apple. Ela vende hardware, é uma fábrica. É uma das empresas mais inovadoras do mundo.

Estimule o intra empreendedorismo

O objetivo final é inovar sim, mas a inovação só vai surgir quando as pessoas pensarem fora da caixa. Para pensar fora da caixa precisam se sentir à vontade, e entenderem que têm liberdade para propor ideias e que elas não serão cortadas.

Foque no “Como”, e não no “O Que”

Uma idéia cujo idealizador julgar genial, mas após avaliação detalhada for descartada, exige muito cuidado:

• Caso o idealizador não receba feedback em tempo justo, ele desmotivará. Não o deixe no limbo;
• Caso o idealizador não seja convencido dos motivos pelos quais sua ideia não será levada adiante, ele desmotivará. Não o deixe sem explicações.
• Ajude o idealizador a identificar a ideia central. Caso não sejam explorados mais cenários em que a ideia é aplicável, o idealizador pode se desmotivar. Ajude-o a entender que criar um novo cartão de crédito já é um meio, mas a inovação pode estar em focar no meio de pagamento.

Comece

Não há cartilha pronta. Só depende de você. Grandes empresas de consultoria proporão modelos prontos, custando milhões de dólares sobre como “implementar a transformação digital”, por exemplo. Não vai funcionar. Sua cultura não deixará. A inovação é incremental. Não terá prazo e custo definidos. Nada é inventado e evoluído ao mesmo tempo (frase de impacto cuja autoria não é minha).

Pense por você mesmo como começar. Estabeleça planos, estude teorias de inovação e como a inovação acontece. Uma vez entendido como a inovação acontece, você saberá por onde começar. Sugestões: Lean, jornadas de design, metodologia ágil de desenvolvimento de software.

A disciplina para aplicar o mindset Lean precisa estar em todo lugar. Neste último sábado, participei de uma aula em que estávamos discutindo ferramentas e preocupações sobre gestão de projetos, focando em riscos.

O cenário Lean

Vamos usar o mesmo cenário de construção civil como exemplo. A maioria das pessoas estava concordando que o projeto seria considerado de sucesso se o entregássemos dentro do escopo, cronograma, custo e qualidade planejado (como o PMI atesta por anos). Isto é muito subjetivo porque irá se basear no entendimento que cada um tem sobre sucesso. Se seu objetivo é somente fazer um check na sua checklist, mantenha o dito acima. Mas vamos explorar uma exceção.

Considere que você é o gerente de projetos. O ponto aqui é: se durante a construção um cano for quebrado e seu projeto derramar rejeitos tóxicos em um rio próximo? Isto causaria um dano ambiental no mínimo. Naturalmente, consertar o cano se torna parte do escopo do seu projeto. Porém não é verdade para todo o restante. Não é sua responsabilidade criar um plano de contorno para a questão ambiental (plantar árvores, limpar o rio, etc), nem se importar com a imagem da sua companhia na mídia e sociedade (campanhas de marketing, levar água para as comunidades afetadas, etc).

Para explorar este ponto, começamos a discutir se você, como gerente de projetos, deveria levar a informação aos donos da sua organização sobre o que aconteceu e o assunto se voltou para a ferramenta MCSW para ajudar nesta avaliação.

Ferramenta MSCW

Fazendo uma pausa, argumentamos sobre a ferramenta MSCW quando estávamos mapeando riscos. É uma ferramenta para classificar a importância do item que está sendo tratado. M é MUST (DEVE constar), S é SHOULD (DEVERIA constar), C é COULD (PODERIA constar), e W é WOULD (“seria legal” constar). Claramente não há um mindset Lean aplicado a esta ferramenta. Deveria ser somente DEVE ou NÂO DEVE constar. É sim ou não. Você precisa ou não precisa fazer algo sobre o requerimento, ou o risco, ou a situação. Discutir os itens do meio será perda de tempo.

A boa índole

Voltando ao cano estourado. DEVERIA ser sua preocupação, como um bom gerente de projetos, alertar e, sugestão minha, ajudar no planejamento de algo para reparar o dano ambiental e a imagem da marca de sua companhia. A bíblia do gerenciamento de projetos diz que você não deve se envolver a não ser que isso se torne parte do seu escopo. E aqui nós temos uma diferença entre empreendedorese pessoas que somente trabalham.

Mas por muitas vezes, o suporte completo às necessidades da organização podem conflitar com o Mindset Lean. Neste caso, alertar sobre o problema é Lean. Porém se envolver na solução não é, a não ser que ela seja adicionada ao escopo. Esta é a hora em que o empreendedor deverá ter maturidade para deixar o problema ser tratado por outras pessoas e se distanciar para focar nos seus desafios reais. Caso contrário, se envolver nas atividades não previstas, será encarado como micro gerenciamento.

Mantendo conhecimento e boa índole perto de você

Um ponto importante de ser exploraado após este fato ter ocorrido são as lições aprendidas no cenário. Esqueça sobre criar um documento escrevendo várias páginas com análises FCA (fato, causa e ação), e colocá-lo num respositório. A parte mais importante é ter certeza de que as pessoas corretas entenderam o que o cenário causou. Por causa do cano estourado, nossas ações despencaram 20% em seus meses, e isto afeta diretamente os empregados na ponta pois perderemos muitos projetos para nossos concorrentes devido a incerteza gerada sobre a qualidade de nosso serviço. Isto pode causar a saída de pessoasda companhia e perda de conhecimento.

A coisa mais importante após os acontecimentos é manter este conhecimento. Certamente você, como gerente de projetos, nunca mais será disciplicente sobre a análise do solo e pesquisas pois estará preocupado com o impacto ambiental. Tudo está ligado. Desde o impacto ambiental até a força de trabalho trabalhando lá.

Muito se discutiu, e ainda se discute, sobre a jornada para nuvem. As grandes empresas do mundo já possuem suas estratégias voltadas para a nuvem desde quando as aplicações são idealizadas. Potenciais de segurança, escalabilidade, autonomia e outros assuntos relacionados já não são mais abordados na hora de discutir projetos. A nuvem já não gera mais dúvidas ou desconfianças há algum tempo. Uma vez que a ida para cloud já é assunto vencido, além dos pontos de atenção já levantados, trago alguns erros que presenciei serem cometidos, como forma de apoiar estratégias de movimentação ou outras:

Encarar nuvem como suporte

A nuvem é protagonista nas aplicações. É muito comum que empresas comecem suas jornadas com rotinas simples de backup ou storage na nuvem para desonerarem seus datacenters próprios. Isto é um passo importante, muitas vezes necessário para passar segurança a um board cético sobre a mudança. Porém as rotinas de rollback, backup, disaster recovery, e outras muito complexas para os times de OPS já são triviais para os grandes players de nuvem. Usá-las com este fim é como subestimar o potencial da nuvem.

Serviços auto-gerenciados possuem nível de automação dos aspectos mencionados acima altíssimo. O time de operações se beneficia de automações de processos que antigamente lhe consumia enorme tempo e dinheiro em planejamento e execução de projetos. Os serviços que não são auto-gerenciados também possuem muita automação embarcada. Backup, rollback e DR são básicos.

Negligência ao executar a matriz de decisão

A opção por um ou outro cloud provider é algo de importância muitas vezes subestimada. Escolher um provedor de nuvem é um casamento que pode trazer relações conturbadas! Tenho visto empresas querendo fugir de seus contratos traumáticos de 10 ou 20 anos com players gigantes como Oracle ou IBM, negligenciando matrizes de decisão de cloud, e assinando outros contratos que os levarão a mais 10 ou 20 anos com X ou Y provider.

Grandes players como Google, SAP, Azure, IBM e SAP permitem um nível de customização altíssimo, que deve ser avaliado na decisão. Estas permitirão configurar todos os aspectos necessários a uma grande aplicação que possua dependências, integrações, relações com outros sistemas e que exigirão práticas customizadas de engenharia. É muito comum também que aplicações complexas possam agregar benefícios de operações em multi-cloud.  Por exemplo: infraestruturas que possuam custo mais atrativo no provider X podem se beneficiar de recursos FaaS de Bigdata do provider Y que é mais veloz ao tratar grandes volumes de dados. Desta forma uma única aplicação pode estar distribuída em mais de um provedor de nuvem, também em mais de uma região geográfica, viabilizando objetivos de negócio como economia, redução de delay e acesso a features exclusivas de players de nicho.

Em paralelo aos grande players, há diversos provedores de nicho de PaaS, FaaS. Digital Ocean, Heroku, Umbler e Elastichosts, por exemplo, são úteis para aplicações que não precisam de tanta robustez. O nível de abstração destas plataformas é altíssimo, o que permite uma curva de aprendizado do time de desenvolvimento e/ou operações muito pequena.

Desconhecer o potencial da nuvem escolhida

A economia que pode ser atingida aproveitando recursos da nuvem, como rollback, DR, backup (citados acima), monitoramento, alertas e ações automatizadas, é altíssima e deve entrar na conta das organizações ao conduzirem seus projetos de migração.

Serviços de PaaS para executar aplicações, ou FaaS para automação de tarefas de redes, Machine Learning, deploy, testes, e outros precisam ser avaliados. Como exemplo cito que toda empresa que possuía software sendo executado em infraestrutura on premise, acabou em algum momento desenvolvendo softwares para amadurecer suas práticas de testes ou deploy. Isto significa que, caso 10 empresas tivessem desenvolvido softwares similares, ao custo de 500h cada, teríamos 5000h duplicadas sendo investidas. Com serviços como CodeDeploy, Device Farm, Fastlane e Firebase, este tipo de desenvolvimento não é mais necessário. Com contratações rápidas, muitas horas de desenvolvimento são economizadas, dando velocidade às empresas, e significando que conseguirão responder às necessidades de seus clientes mais rapidamente.

Falta de rastreio sobre o investimento

Ainda é comum que o orçamento para cloud seja uma caixa preta. O rastreamento detalhado deste investimento deve ser mantido por pessoas capazes e ser separado por aplicação/negócio/o que fizer sentido naquela realidade. Desta forma decisões assertivas poderão ser tomadas, como a contratação ou descontinuação de determinado serviço contratado. Isto é mais uma prática que evita que o “casamento” com o cloud provider possa se assemelhar aos contratos de muitos anos com Oracle, IBM e etc, dos quais toda grande empresa tenta fugir hoje. Já cometemos erros no passado. Vamos aprender com eles!

Falta de atualização do time responsável

Como exemplo, ainda é comum empresas investirem grandes quantias de dinheiro comprando muitos diferentes aparelhos móveis para testar seus aplicativos. O desconhecimento dos serviços que permitem testes automatizados nestes dispositivos fará com que este dinheiro continue sendo desperdiçado e benefícios da automação disponível não cheguem até o processo de desenvolvimento.

Com cada vez mais competidores qualificados de nicho surgindo, a falta de atualização pode ser um grande problema. Desconhecer boas alternativas a serviços já existentes e consumidos pelas empresas, fará com que elas nunca sejam descobertas e seus benefícios não sejam utilizados.

Tendo experiência em gerenciamento de muitos projetos em muitas metodologias diferentes e diferentes misturas delas, recentemente pude identificar algumas características que acontecem em todos estes cenários e tornam um projeto suicida na forma de se gerenciar. Por suicídio me refiro a um projeto que encontrará problemas e decairá até que alcance um ponto inaceitável, levando a perda de um cliente ou algo extremo como isto.

Os itens abaixo foram identificados como algo comum a todas as formas de gerenciamento, e se qualquer um deles for comum a você ou parte da sua rotina, é hora de mudar algo. Alguns deles se referem ao relacionamento entre as pessoas e alguns deles a práticas técnicas.

Sem ambiente de QA

Um projeto que tem somente um ambiente formal de produção. O desenvolvimento é feito pelo time nas suas próprias máquinas. Não há ambiente de QA (Quality Assurance).

Parece loucura, certo? Mas ainda acontece. Geralmente acontece quando quem está pagando a conta não entende quanto catastrófico pode ser não ter um ambiente de QA / Testes / Homologação. Quando isto acontece, você está lidando com sua sorte diariamente, como a imagem acima.

O ambiente de QA deve ser, idealmente, uma cópia exata do ambiente de produção. Rotinas de cópias de PRD (produção) para QA precisam ser mantidas de tempos em tempos. Quando isto funciona, sempre que um problema em PRD aparecer, será mais rápido para identificar e simular em QA. Se é mais rápido de simular, é mais rápido encontrar uma solução e consertar PRD. Quando um problema em PRD é solucionado rapidamente, o cliente perde menos dinheiro relacionado àquela falha, ou no mínimo sua marca é menos afetada devido àquela parada.

Podem haver diferentes formas ou requerimentos mínimos para ter pelo menos um teste confiável antes de enviar código novo a PRD. Os dados de QA podem ser diferentes dos atuais de PRD. Os ambientes podem ter diferentes configurações de hardware e etc. Mas quando mais diferenças houver entre QA e PRD, mais tempo será gasto rastreando problemas.

Falando sobre um serviço diferente, quando você não possui um ambiente de QA, é o mesmo cenário de um médico tentando um novo método cirúrgico que não foi testado em ratos ou macacos antes. Pode até funcionar. Mas há uma grande chance de dar errado. E quando funciona, é sorte.

Zero automação

Quanto mais automação você tiver, menos erros humanos acontecerão. Pessoas vão falhar. Isto é normal! Vamos deixar que as pessoas pensem no que realmente importa e não em atividades de rotina. De alguma forma isto irá acontecer algum dia:

• Vão commitar o último código na branch errada. A produção vai parar;
• Vão esquecer de executar um script antes de deployar um pacote. A produção vai parar;
• Vão esquecer de rodar um teste mínimo programado antes de executar um novo processo ou serviço. A produção vai parar;

Uma boa forma de prevenir estes erros é automatizar a maior quantidade de coisas que puder.

Um bom ponto de partida pode ser automatizar a atividade de deploy. Muitas companhias com que me relacionei ainda possuem problemas com processos de deploy. Elas planejam com 4 semanas de antecedência. O deploy é feito. Dá errado. Requer mais uma ou duas semanas para consertar o código e colocar a produção para rodar novamente. Então planejam o próximo com dois meses de antecedência. Dá errado novamente. Se o deploy é um problema, porque não torná-lo algo trivial? Tente fazer todos os dias. Muitas coisas serão aprendidas.

Automatizar testes também é uma ótima iniciativa. Testes automatizados são uma das melhores armas para estabilidade de software. Quanto maior for a cobertura de testes, mais estável a aplicação será. Estas duas sugestões vão requerer tempo para serem implementadas, mas seus benefícios serão sentidos na credibilidade do software por toda a companhia.

Falando de um serviço diferente, não ter automação é como carregar um armazém caixa por caixa, sem uma empilhadeira. Muito tempo será desperdiçado, é claro. Mas também muitas caixas serão derrubadas. Muitas serão chacoalhadas demais. Vai funcionar, mas muitos riscos são adicionados ao processo desnecessariamente.

Displicência dos usuários chave

O responsável por testar seu projeto é o ator principal da sua rotina. A opinião dele será questionada sobre quaisquer óticas e práticas. Esta pessoa precisa estar comprometida e viciada no seu projeto, ajudando e apontando dedos a qualquer coisa que dê errado.Os melhores projetos com os quais já me envolvi tinham pessoas muito minuciosas testando e dando seu OK às features entregues.

Se o seu projeto carece desta preocupação, alguns problemas podem surgir:

• Falta de percepção de valor. O que você vêm praticando/dizendo não é o que o cliente gosta de ver/escutar;
• Falta de alinhamento entre o que é desenvolvido em comparação ao que adiciona valor ao negócio;
• O pior deles: falta de conhecimento sobre o sistema. Esta pessoa deveria ser quem conhece todo o sistema. Se ela não o faz, muitos problemas podem aparecer em função de diferentes concepções sobre porque algo foi desenvolvido de certa forma, e não de outra.

Este exemplo é como uma mãe que não se importa com a edução de seu bebê. Ele vai crescer, é claro. Mas pode se tornar uma bomba relógio.

Fraco julgamento para escolhas tecnológicas

Tecnologia é algo sério e não pode ser tratado como tendências de moda. Tendências de moda vêm e vão e se renovam de tempos em tempos. Uma linguagem de programação, framework, feature, provedor de cloud, e todo o restante relacionado ao desenvolvimento, não podem ser eleitos porque são legais ou por serem a coisa de que todos falam, a moda. Todas estas decisões precisam ser questionadas pelo time de desenvolvimento e, se possível, contar com ajuda de alguém de fora do projeto para pensar junto com o time e alcançar a melhor escolha.

Quando alguma má escolha tecnológica é feita, alguns problemas podem surgir:

• Dificuldades de encontrar profissionais que conheçam aquela tecnologia para trabalhar com seu projeto;
• Problemas no futuro devido a incompatibilidades daquela tecnologia com os requisitos do projeto;

Usando o paralelo com outros serviços, usando uma tecnologia que não está provada ainda é como comprar um hamburguer com bacon vegano dentro dele. Pode ser bom, mas ainda não temos certeza. É uma aposta.

Comunicação/status deficiente

Como está estruturada a rotina de comunicação com o seu cliente? Você tem um momento formal para compartilhar informação? Ou você faz isso baseado em um gatilho? Neste ponto não há resposta certa, como sugerido no artigo “A resposta mágica para gerenciamento de projetos de software“.

Mas você terá um processo para compartilhar informação e dizer o que você tem feito a quem quer que esteja pagando a você. Pode parecer estranho, mas compartilhar informação pode ser um problema sério em muitos projetos. Você precisa ter certeza de que as atividades que você está conduzindo fazem sentido ao cliente, e ele entende que o que você está fazendo é bom para o negócio. Você tem reuniões semanais? Diárias? Um status report?

Quando você não tem um processo para dar feedback sobre o que você está fazendo, é como investir dinheiro com uma empresa de investimentos que não te informa sobre seus ganhos.

Porque atacar tudo isso?

Todas as constatações acima se referem a práticas que precisam ser consideradas em seu projeto. Caso contrário, os problemas em seu relacionamento ou nos dados da aplicação serão evidentes. Quando qualquer um dos pontos abordados acontecem, significa perda de dinheiro ou pelo menos enfraquecimento da marca envolvida. Pode ser natural que o aplicativo principal de um banco não tenha grandes problemas. Mas o usuário não gostará quando o registro para aquele programa de cashback quebra. Significa que o banco não é sério frente a seu usuário e sobre suas campanhas de marketing.

Nós automatizamos coisas desde o início da história humana. Os moinhos “ligados” através da água desccendo pelos rios pode ser considerado como uma automação para processar sementes. Muitas discussões têm crescido ultimamente devido ao fator automação. Mark Zuckerberg e Bill Gates já se pronunciaram sobre os impactos das iniciativas mais recentes de automação.

Falando sobre projetos em TI, um comentário que estou muito acostumado a escutar de muitos grupos de pessoas é o questionamento sobre o que acontecerá com o atual trabalho das pessoas.

A automação sempre existiu

Como mencionado no artigo “Uma visão sobre a evolução da TI“, a TI sempre foi encarada como um braço para automação. Desde quando foi  criada até hoje, nós estamos acostumados a automatizar planilhas para que o trabalho possa ser feito de formas descentralizadas. Muitas pessoas trabalhando sobre a mesma atividade cria a necessidade de um sistema. Quando ele é criado elas podem se comunicar e obter vantagens sobre a informação de todas as pontas. Por exemplo: pessoas da logística precisam avisar o time que cuida da portaria para deixar que os caminhões saiam quando os mesmos são carregados. Se não houvesse um sistema para apoiar, pessoas precisariam ligar umas para as outras a cada 5 minutos, ou ainda precisariam de alguém correndo por toda a planta durante o dia.

Mas o foco da indústria foi mantido dentro da indústria por muitos anos, uma vez que as empresas eram quem tinha máquinas e dinheiro para comprá-las.

Agora esta escala mudou

Hoje em dia todos possuem um smartphone e internet. Com isto, muitos novos negócios foram criados. Agora a automação, e novos negócios, podem alcançar milhões de pessoas facilmente.

• O Uber veio e criou um modelo de negócios que liga clientes a fornecedores. Uber, iFood, Archie e muitos outros estão colhendo os benefícios deste modelo. Não há mais intermediários envolvidos.
• Bancos digitais – como as pessoas encaram o dinheiro hoje? As agências são vistas vazias facilmente hoje em dia, devido ao movimento de levar conveniência às mãos das pessoas. Grandes bancos do Brasil já não possuem mais ATMs espalhados pelas ruas.
• Varejo – pessoas se frustram quando vão a shoppings por uma série de fatores. Há muitas pessoas competindo por atenção, as filhas são estressantes e sempre há o risco de se mover de suas casas até as lojas. Não podemos negligenciar que a maior loja de todas as companhias de varejo é a online.

Novas oportunidades

Como enfatizados por Gates e Zuckerberg, muitas pessoas podem encontrar uma mudança em seus empregos. Elas podem se tornar obsoletas devido a mudanças do mercado. Mas sempre que uma mudança acontece, muitas oportunidades são trazidas juntamente. A responsabilidade das grandes companhias e empreendedores, sempre que eles automatizam algo, é permitir que as pessoas façam o que as máquinas não podem: pensar. A automação traz muitos benefícios:

• Qualidade – todo processo será executados da mesma forma. Então melhorando aquele único ponto afetará todas as execuções do processo;
• Previsibilidade – com maturidade e tempo você saberá o que esperar das suas ferramentas. Então você pode planejar com antecedência;
• Economia de tempo – padronização traz velocidade naturalmente. Vamos melhorar aquele ponto único até atingir a melhor performance possível;
• Métricas – usando práticas de telemetria você pode obter métricas para tomar decisões sobre quais pontos você deve melhorar primeiro;
• Redução de custos – tendo todos os benefícios acima, o ROI direto será encontrado facilmente;

Para as companhias e empreendedores, automação significa economizar dinheiro em determinado processo. As pessoas que terão seu tempo economizado já possuem muito conhecimento sobre o negócio e sobre o processo. Suas novas responsabilidades são pesquisar e pensar em formas de melhorar o processo. Máquinas ainda não podem pensar como pessoas.

O que vem além?

Durante os anos recentes, temos encarado um novo mindset quando falamos sobre provedores de serviço levando facilidade aos seus clientes. Uber, iFood, etc são exemplos de um modelo de negócios criado por um dos passos da história da automação. Quando falamos sobre automações em larga escala, um dos passos certamente receberá a influência do blockchain. O que ele faz é remover os intermediários de processos de manuseio de dinheiro, fazendo com que uma ponta chegue até a outra sem assistência. Desta forma dinheiro é economizado. Blockchain também possui potencial para afetar coisas não somente relacionadas ao dinheiro. Quais podem ser as próximas indústrias afetadas pela automação nesta escala?

Seguindo uma série de artigos já escritos aqui, uma das atividades que considero muito importantes e de que gosto muito é a criação do “status report” para coisas que dependem de mim. (Este exemplo prático foi criado algumas semanas atrás para um projeto real).

Status report não é somente para projetos!

Status report é uma coisa maior, e gerar status reports não é uma atividade somente para projetos, mas também para tudo que depende de você. Alguns exemplos:

• Contar ao seu líder o que, sobre aquela atividade chave à companhia, avançou durante a última semana;
• Contar às pessoas o que você aprendeu durante aquele evento importante;
• Contar às pessoas como seu projeto está indo (é claro);
• Gerenciar seu time;
• Pensar consigo mesmo sobre seus planos de vida. Pode ser sua ferramenta para o momento de retrospectiva pessoal;

Se você quiser enviar a alguém (seu líder por exemplo), ou não, o status report é um momento onde você precisa parar tudo o que está fazendo e analisar tudo o que realmente importa “de cima”.

Criando seu próprio modelo

O que você deseja reportar? Partindo de muitos status reports com que já lidei, provavelmente a informação mais básica é: data (quando o relatório foi gerado), últimos updates (pontos relevantes textualmente) e KPIs (números executivos). Você também precisa ter em mente quem receberá este arquivo (se o seu plano for enviar de alguma forma). Qual é a linguagem que estas pessoas entendem? Seu discurso precisa ser mais executivo? Ele pode ser bastante detalhado (provavelmente não)? Abaixo listo algumas sugestões para alguns tipos de status reports falados acima:

Status report para atividades chave

Você pode pensar em enviar sua informação no corpo de um email, de acordo com quão pequeno e/ou importante é sua informação. Depende de quão formal você quer ser.

• Data – a informação está dentro de um email? A data de envio do email pode ser a sua informação. Caso contrário, diga qual é a data em que o snapshot foi tirado;
• O que é a atividade? Quando você olha para esta informação, ela o ajudará a manter o foco no que realmente importa e remover da sua frente qualquer coisa que não esteja alinhada com seu objetivo principal. Qual é o resultado esperado?
• Dependências – dependências de fornecedores e cronograma são muito importantes. Qualquer coisa de que você dependa precisa estar explícita, porque pode afetar seu progresso;
• Atualizações – informação geral relevante. Exemplo: durante esta semana, as atividades X e Y foram finalizadas. A última, Z, será finalizada dentro de duas semanas. Também o escopo ou algum fato importante sobre uma atividade chave mudaram.
• Novidades! – você está pesquisando uma tecnologia nova para a companhia? Uma boa seção pode ser novidades sobre aquela busca, tendo seu conteúdo vindo de influenciadores conhecidos.
• KPIs – como você pode medir quão perto você está de atingir o objetivo da atividade?

Status report sobre resultados de eventos

Então a companhia está investindo enviando você para um importante evento na sua área. Faz sentido que você faça com que todos saibam o que você aprendeu e compartilhe a nova informação com qualquer pessoa que a queira. Imagine que serão 4 dias de eventos, então uma compilação por dia pode ser interessante:

• Data – qual é o dia dentro do evento?
• Quais foram os principais assuntos? – Quais foram os assuntos que você escutou dos palestrantes? Você conheceu alguma nova tecnologia importante? Quem estava lá falando? Esta pessoa era alguém  conhecido largamente? Qual era seu perfil no LinkedIn?
• Descrições sobre tudo – Seja conciso mas também diga tudo de relevante que foi falado. Como você e sua companhia podem se beneficiar daquele discurso? Você pode sugerir uma estratégia para se mover em direção daquela opinião/tecnologia?
• Opiniões! Uma vez que você esteve lá, dê sua opinião. O discurso foi legal mas você tem suas dúvidas sobre o potencial? Diga!

Um status report comum de projeto

Status report sobre progresso de times

Se você é líder de um time, um status report pode ser muito útil para manter olhares regulares a seu próprio trabalho como líder. Vamos ter uma visão clara sobre como seu time está trabalhando! Isto irá, em vários momentos, cruzar com o status report regular (acima), mas há mais coisas para se olhar quando falamos sobre times, e não apenas projetos.

• Data – a data em que o snapshot foi criado;
• Operação / atividades regulares – é básico. Como as suas atividades normais estão indo? Crie um KPI rápido aqui: está tudo OK ou não? Você está dentro do cronograma das suas atividades regulares? Extraia esta informação do status report sugerido acima;
• Cliente – como está seu relacionamento com o cliente? Você sabe quem o responsável por tomar decisões importantes dentro do projeto? Quem são os atores chave que você deve monitorar tudo que eles dizem? Qual é a atual opinião direta sobre seu relacionamento com eles neste momento? Uma pesquisa de satisfação, conduzida por alguém de fora, pode ser muito útil;
• Saúde do time – todos do seu time estão satisfeitos com seus trabalhos? Como o trabalho se encaixa nos planos de carreira deles? É seu trabalho garantir que todos estejam devidamente motivados e cheios de energia;
• Novidades – como estão seus planos para melhorar? Porque não mostrar os planos para um novo processo que você esteja elaborando para aumentar o conhecimento das pessoas? Também mostre que está tentando chegar a um novo interlocutor dentro do cliente com quem você ainda não possui relacionamento. É hora para olhar tudo o que importa dentro das suas responsabilidades e elaborar planos para melhorar estes aspectos;

Próximos passos

Quando você precisa fazer com que as pessoas saibam sobre seu status report, ele deve ser apresentado, não apenas enviado. A coisa mais importante depois de um grande status report, é obter feedback. O feedback também virá de você mesmo quando você estiver atualizando o arquivo, e não apenas das pessoas que receberão o arquivo. Então, toda vez que você encontrar algo que não esteja da forma que você planejou, será hora de planejar e tomar ações para colocar aquela seção de volta nos trilhos.

Status report é uma ferramenta poderosa para vários assuntos e intenções. Este exemplo prático traz um cenário real criado por mim algumas semanas atrás e mostra uma abordagem para passar a mensagem às pessoas que importam.

O modelo está apresentado, e todas as seções também estão descritas abaixo, mostrando qual é a intenção e porque faz sentido a este cenário. O documento está DISPONÍVEL AQUI (inglês e português) e você pode utilizar em seus projetos livremente.

O modelo

Identificação, gerente de projeto, objetivo e data

Estas quatro seções são muito importantes para garantir que todos que abram seu arquivo saibam exatamente sobre que projeto você está falando.

• Cliente X – Qual é a empresa pagando e interessada pelo seu projeto? É importante para você e para qualquer pessoa dentro da sua empresa entender;
• Projeto Y – Qual é o nome do projeto? Esta é a identificação para qualquer um que receba este arquivo entender seu propósito;
• Gerente de projetos – Quem é o responsável por este projeto? Em todas as pontas que importam a você. Neste caso apenas minha companhia e o cliente foram importantes. Você pode adicionar outros fornecedores por exemplo;
• Objetivo – Seu objetivo principal. É importante para manter o foco. Uma vez que este arquivo é acessível a todos do projeto, todos precisam entender a que eles estão contribuindo e se sentir parte daquilo;
• Data – mostra o período a que o arquivo se refere. Mantenha histórico dos seus status reports! Isto permitirá que você acompanhe seu progresso, as coisas que você já tentou ou está tentando, e como elas estão indo;

Status, logos and datas planejadas

• O status geral é uma informação executiva e para onde todos olharão. É uma mensagem simples mostrando como seu projeto está indo. Não se trata de como você acha que está indo. Você precisa ter números para definir. Neste documento foram usados 3 KPIs (mostrados abaixo) e as regras foram: se todos estiverem verdes, o geral é verde. Se pelo menos um estiver amarelo, amarelo é o geral. Se qualquer um estiver vermelho, todo o projeto está vermelho;
• Os logos (seu e do seu cliente) possuem uma mensagem importante sobre a parceria responsável por conduzir este projeto. Isto passa uma mensagem subjetiva mostrando a todo o time como as duas companhias estão engajadas para alcançar o mesmo objetivo;
• A data fim original é a primeira data planejada para finalizar o projeto de acordo com o cronograma;
• A data fim replanejada é preenchida somente se você precisou replanejar sua data de finalização por alguma razão. As razões precisam ser mostradas nas atualizações (exemplos abaixo) quando um replanejamento acontecer;

Riscos, mudanças e dependências

Qualquer acontecimento aos riscos e mudanças precisam ser verificados por você, como gerente de projetos responsável, para entender se requererão qualquer tipo de replanejamento. Pode afetar seu cronograma, seus custos, pessoas envolvidas, recursos externos, fornecedores, etc;

• Riscos é onde você lista tudo que pode afetar seu projeto e mudar algo planejado. É comum que seja algo fora de seu controle, então tenha um plano para cada um dos riscos para lidar com problemas quando algo der errado;
• Mudanças precisam ser preenchidas quando algo relevante acordado foi alterado por alguma razão. Uma decisão foi repensada? Faça com que todos saibam;
• Dependências é uma seção usada quando você tem tarefas dependendo do esforço de outras pessoas ou times. É muito importante pois se eles se atrasam, você precisará tratar o impacto;

O exemplo possui uma dependência com um deadline tachado. O objetivo é mostrar que uma entrega planejada não foi finalizada e precisou ser replanejada.

Também há uma dependência com um deadline pintado em vermelho. Isto se refere a uma tarefa que precisa ser desenvolvida por alguém fora do time original do projeto. Precisa haver uma pessoa responsável e também uma data quando o entregável será de fato entregue. Se a tarefa está atrasada, todo o projeto poderá ser atrasado.

Atualizações

Esta seção é a que terá maior quantidade de informações sendo mudadas de semana para semana. Todo seu conteúdo pode ser mudado de uma semana para outra. Aqui é onde você listará tudo o que aconteceu, pessoas adicionadas, resultados de testes, entregas de outros fornecedores e etc. Também gosto de manter dois sub-tópicos: o que foi finalizado durante a última semana, e o que será feito na próxima.

Cronograma

O cronograma faz sentido quando você está lidando com um projeto com escopo fechado ou não. Você pode usar para dar visibilidade sobre a próxima entrega importante quando estiver gerenciando projetos ágeis, por exemplo. Você pode mostrar atividades macro ou ainda mostrar 100% de todo seu planejamento (como o exemplo mostra).

O exemplo lista as tarefas e as dá cores:

• Quando verde, está pronto para ser desenvolvido;
• Se está laranja, depende de algo externo e não pode ser iniciado no momento;
• Para vermelho, significa que está atrasado por alguma razão;

Também mostra as tarefas planejadas para serem entregues durante a semana (destacada em laranja na primeira linha da tabela). Estão representadas pelo X na célula respectiva. E por último mostra o percentual de cada uma das tarefas;

KPIs

As métricas que você decide medir durante o projeto. Para este, pessoas, escopo e datas eram os aspectos principais. A tabela mostra a métrica e o status de cada uma. Quando você tiver algo diferente de verde, você deve escrever o motivo que justifica aquela métrica não estar indo bem. Não esqueça de adicionar os custos à seção de KPIs;

Comecei a pensar neste artigo como minha retrospectiva de fim de ano. E percebi que a maior coisa que aprendi durante o ano é sobre engajamento.

Tenho escutado, durante anos, que “80% dos projetos que falham, falham por causa de falta de comunicação”. Esta é uma verdade triste, mas neste ano percebi que esta é uma fácil e confusa abstração. Quando você fala que comunicação é o problema, você está escondendo vários problemas sérios,  não apenas no seu projeto, mas também em sua organização. E após este momento eureka, um novo momento veio: “pessoas se comunicam da forma correta” se estão engajadas e têm suporte para se desenvolver.

Alguns exemplos

1. Temos um contrato para monitorar uma aplicação online. Não é muito crítica, mas ainda temos SLAs para cumprir quando há algum problema. Então um problem vem e a pessoa de OPS esquece de avisar ao cliente, durante os primeiros 15 minutos, que ele está procurando uma solução. Além disto, ele toma uma hora além das 4h planejadas, para resolver o problema. Isto causa uma discussão durante uma reunião entre os gerentes e todos finalizam o assunto dizendo que tiveram um problema de comunicação.
2. Evoluímos uma solução bastante crítica, que trabalha com o dinheiro de um cliente. Então um desenvolvedor não cria o test automatizado e o aplicativo quebra quando vai para produção. Isto causa uma discussão durante uma reunião entre s gerentes, e todos concordam que o profissional de QA não se comunicou corretamente com o desenvolvedor sobre o teste faltante.
3. O gerente de projeto avisa que o projeto está atrasado, mas não diz o quanto. Quando alguma coisa vai mal e alguém pergunta sobre, ele defende a si mesmo dizendo que contou sobre o atraso, e houve um problema de interpretação porque aqueles que leram não entenderam a mensagem da mesma foram que ele quis dizer. Então após mais uma reunião, todos concordam que ele não se comunicou da maneira correta.

Porque acontecem

O que aprendi durante este ano, sobre engajamento, foi a identificar porque estes exemplos acontecem:

1. A pessoa do time de OPS não contou ao cliente que estava trabalhando já nos primeiros 15 minutos, e esqueceu de avisar que tomaria mais uma hora para resolver o ticket, porque ele não estava de fato empoderado de sua posição. Ele não entende a vitalidade de sua posição. Se ele esquece de avisar ao cliente sobre o down time, o cliente não poderá avisar aos usuários. Os usuários começarão a acionar o call center. Então pelo menos 10 pessoas terão mais trabalho para fazer, forçando a empresa a pagar por horas extras, por causa de uma informação faltante. A pessoa de OPS não teria esquecido de contar a ninguém necessário caso ele entendesse todo o cenário.
2. O segundo exemplo não tem nada relacionado ao QA. A responsabilidade afeta o desenvolvedor. Ele não criou o teste porque não sabe que a cada hora do sistema parado, o cliente perde US$ 10.000,00. Ninguém, quando velho, irá querer contar histórias aos seus filhos dizendo “hey, uma vez eu parei o sistema de produção, e estraguei a vida de várias pessoas”. Então o desenvolvedor foi negligente sobre o teste porque não estava de fato empoderado de suas responsabilidades e atribuições.
3. A intenção do gerente de projeto não é esconder informação. Ele é pago, essencialmente, para manter as pessoas informadas. Quando ele espera um ou dois meses para dizer que o projeto está 2 meses atrasado, ele não pensa que as pessoas necessárias ao projeto serão demandadas no próximo, e que isto causará prejuízo à companhia. Uma vez que as pessoas não estarão disponíveis, o projeto original não terá orçamento suficiente, e toda a companhia precisará gastar mais dinheiro para contratar novas pessoas para o próximo.

Então se você está dentro de qualquer um destes exemplos, pense no outro lado como se fosse um amigo seu. Você deixaria qualquer um destes exemplos acontecerem se soubesse o quão profundo eles afetarão?

Resolvendo da forma errada

É fácil pegar estes problemas e rotulá-los como problemas de comunicação. Então nossas cabeças técnicas pensarão em processos para garantir que:

1. O sistema de tickets envie emails automaticamente avisando o cliente de que estamos trabalhando sobre o problema;
2. Nós criaremos uma integração entre a ferramenta de aceitação de tarefas e o repositório de código para verificar se todas as tarefas têm pelo menos um teste desenhado;
3. O gerente de projeto sempre apresentará o status report tendo o cliente ao seu lado, então nenhuma informação será perdida novamente;

As sugestões acima não estão erradas e não devem ser encaradas como algo para ser evitado. Mas elas precisam ser a última alternativa. Elas são remendos para a falta de engajamento das pessoas.

Resolvendo da forma correta: construa

As pessoas são boas. Quando você compartilha, da forma correta, as responsabilidades delas e como as atividades delas afetam as outras, elas se sentirão como parte do grupo e tentarão sempre ajudar a todos. Então porque não perguntar a cada um dos atores destes exemplos como eles resolveriam o problema? Apresente o problema, diga tudo o que aconteceu ou pode acontecer em função do comportamento deles. Como resolver? Esta é a parte mais difícil. Provavelmente a primeira coisa a vir não será a solução perfeita ou a solução em que você pensou. Então é hora para mostrar uma solução melhor e verificar se ela faz sentido àqueles que a colocarão em prática. Um mix das ideias pode ser um bom início.

E começamos a falar sobre a maturidade das pessoas para resolver problemas:

• Se eles são junior com um bom potencial, apenas envolvendo-os e contextualizando-os sobre suas responsabilidades pode resolver o problema. Eles possuem boas intenções! Eles não esquecerão de contar a ninguém o que estiver acontecendo da próxima vez;
• Se eles estão sobrecarregados, você aconselhará sobre procurar ferramentas para auto gerenciamento. E também ajudará a focar no que é importante e a não ficar sobrecarregado novamente;
• Se você identificar que é necessário, porque não usar uma das soluções processuais descritas acima como o caminho errado? Tome cuidado porque elas precisam fazer sentido para todos os afetados. Depende da maturidade das pessoas para que não se sintam forçadas;

O objetivo é olhar para o mindset de empowering e de colaboração (networks), como descrito na imagem abaixo:

Sempre tenha próximos passos

Certa vez fui convidado para participar de uma retrospectiva. O objetivo era ajudar um time com uma visão externa para que eles pudessem melhorar seus processos. A primeira coisa que perguntei foi onde estavam os “próximos passos” da retrospectiva anterior. Para minha surpresa, não havia próximos passos.

Sempre mantenha histórico dos objetivos e resultados. Isto lhe dará senso de melhoria, e se não der, será fácil encontrar onde os novos erros foram cometidos. Tenha um checkpoint periódico sobre cada um dos cenários acima, até que eles se encaixem em uma estrada em que os problemas não aconteçam novamente.

Depois disso, quando você tiver a solução completa, você poderá ainda compartilhar sua boa prática com outros times próximos de você:

• O que aconteceu; Porque aconteceu; Quando aconteceu;
• O que você fez para resolver, quais foram as primeiras tentativas, o que realmente resolveu?
• O que você aprendeu disso? Próximos passos;