Arquivo da tag: execução

0

Do Takt Time do Lean ao Tiki-Taka do Barcelona

|

Os conceitos e fundamentos do Lean sobre fluxo são essenciais para entender métodos ágeis. Tem a ver com a percepção de produtividade e efetividade, evitando a sensação de trabalhar muito e não ter os resultados e reconhecimento desejados. Então vamos falar de Takt Time e cadência  \o/

Takt Time é o tempo dividido pela demanda na indústria Lean, um fundamento essencial ao conceito de sistemas puxados, se for rápido demais gerará stress e estoques intermediários, se for lento demais gerará ociosidade e descompasso, ambos induzindo ao erro e desperdícios.

Cadência é o estabelecimento de um ritmo sustentável e equilibrado entre recursos, pessoas, tempo e produção, com valor e qualidade. O segredo é encontrar um ritmo constante que mantenha o fluxo, desafiador mas possível, seguro mas não pessimista.

SCRUM

Equipes que seguem o método SCRUM são impelidas a trabalhar com conceitos e regras que os induzem ao estabelecimentos de seu Takt Time e cadência a cada projeto, de forma iterativo-incremental-articulada, ajustando conforme avançam e aprendem.

Baseado nesta premissa conceitual eu propus o Scrum Setup Canvas antes do planejamento do Release PLan, de forma a levarmos em consideração os vetores e variáveis que influenciam as estimativas em cadência, validando nossa capacidade a cada sprint.

Os instrumentos oferecidos com sucesso pelo método é o DoR (Definition of Ready) e DoD (Definition of Done), o primeiro estabelece os critérios que permitirão o desenvolvimento de cada história de forma eficiente, o segundo são critérios para considerar cada história pronta para o cliente.

o Dor e DoD estabelecem o ritmo de um time, que proporcionará um compasso estabelecendo mínimo desperdício e alta performance sustentável para entrega contínua de valor ao cliente com a qualidade estabelecida e acordada.

A intenção é estabelecer um ritmo cadenciado entre o DoR e DoD, enquanto os desenvolvedores trabalham no desenvolvimento partindo do DoR das histórias do sprint corrente até seu DoD, colegas trabalham para o estabelecimento do DoR do próximo sprint, orquestrando a evolução.

KANBAN

No kanban temos o conceito de fluxo contínuo, método que utilizo muito para equipes de sustentação. Neste caso, não temos o Release Plan, DoR e DoD como no Scrum, pois trabalha foco naquilo que é mais importante a cada momento, não constituindo sprints, mas continuamente.

Mas o mesmo mecanismo é utilizado de forma diferente, priorizadas as alterações corretivas ou evolutivas o time vai puxando conforme escala e trabalhando de forma a entender, executar e atender, entregando valor e qualidade sem o estabelecimento de demandas para cada duas semanas de trabalho.

Neste caso, ao se utilizar de suas boas práticas, teremos um quadro físico ou virtual com a evolução de status até estar pronto, regras explícitas, estabelecimento de quantidades, monitoramento de fluxo com métricas como lead time, cycle time, throughput, burn down, cumulative flow.

Na prática, a essência do conceito de equipes de alta performance diz mais respeito a cadência coletiva que a produtividade individual, quais as técnicas que nos auxiliam a práxis de comunicação ativa, colaborativa e tomadas de decisão a cada dia em prol de eficácia e eficiência em processo e produto.

TIKI-TAKA

Uma analogia descompromissada com o famoso conceito Tiki-Taka do Barcelona e seleção espanhola, definido como um sistema baseado em posse de bola através de passes curtos utilizando todos os espaços do campo e todos os jogadores, a bola não para, cada jogador sempre com múltiplas opções de passe rápido.

No sistema catalão, também usado pela seleção espanhola, todos os jogadores participam direta ou indiretamente da jogada, movimentando-se de forma a serem uma opção para receber a bola e passar a outro colega, mantendo o ritmo, atenção e colaboração ativos sempre, envolvendo o adversário e, com frequência, vencendo.

CONCLUSÃO

Os desperdícios do Lean dizem respeito a tudo o que possa comprometer nosso Takt Time e cadência de valor, produção apressada com estoques intermediários inúteis e de alto risco, movimentação indesejada, execução defeituosa, foco fora da prioridade a cada momento, tudo isso dinamicamente.

Fazer certo a coisa errada é tão ruim quanto fazer errado a coisa certa, é preciso fazer certo a coisa certa, um passo de cada vez, de forma cadenciada, sempre iterativo-incremental-articulada, com pequenos e contínuos ciclos sustentáveis, projetando, executando, validando e corrigindo.

Não é tão difícil assim, é só começar a andar e a cada ciclo ir experimentando, aprendendo e melhorando, deixando as retrospectivas fazerem seu trabalho. Como disse o Bilbo Bolsseiro, “Você pisa na Estrada, e, se não controlar seus pés, não há como saber até onde você pode ser levado …” \o/

0

A equação CAPEX += OPEX é essencial para bons gestores e equipes

|

Quer na vida, empresa, futebol, política, é preciso entender o valor de trabalhar com equilíbrio entre metas de curto, médio e longo prazos, desdobramentos, ganhos e perdas. O brasileiro trata CAPEX e OPEX em suas empresas da mesma forma que gerencia times de futebol ou política, muitas vezes imediatista, oportunista, pró-geração de factóides.

Não entendam o tom de meus posts como acusatórios, são situações que nos circundam em diferentes graus, o que precisamos as vezes é um balde de água gelada para se propôr a debater com mais realismo as consequências de atos nossos (conscientes ou inconscientes). A equação certa é CAPEX += OPEX, significa CAPEX = CAPEX + OPEX.

CAPEX (expenditure) ~ despesas ou investimentos em bens de capital; despesas de capital; aquisições.

OPEX (operational expenditure) refere-se às despesas operacionais, recorrentes, continuadas.

CAPEX é investimento, aquisição, projeto, mas cada tomada de decisão ali pode aumentar ou diminuir sua OPEX, custo recorrente de operação que muitos geram como a maldição da múmia. Um projeto mal feito, imediatista, enrolada em retalhos, terá que ser mantido com doses maciças de recursos super-dimensionados por anos para fazer frente a tudo o que não foi feito em alguns meses mal geridos de projeto.

Sempre cito paradigma e risco da Teoria da Agência, pois ‘empresa’ não existe, existem CEO, VP’s, diretores, gerentes, profissionais, as vezes inconscientemente com foco em objetivos pessoais ou zona de conforto. Projetos precisam ter no radar uma visão de longo prazo, evitando acordos onde todos se beneficiam, menos a empresa.

Reflexão: Estudos sobre Linha de Produto de SW demonstram um custo inicial para a absorção e qualificação, sendo mais oneroso começar a fazer diferente do que fazer mais do mesmo, até um breakeven, quando então passamos a obter os resultados melhores desejados, cumulativamente, cada vez mais – Vale para muitas técnicas e tecnologias!

lps_figura1

CAPEX e OPEX – ESTUDOS DE CASOS HIPOTÉTICOS

Um projeto de software construído sob muita pressão pode gerar elogios, bonificações e promoções pelo CAPEX, mas com práticas inconsequentes afetando sua OPEX. Um projeto construído com muita pressa, pode ganhar elogios, mesmo com tecnologia inadequada, desde que atenda a necessidade. Tem até casos em que não se documenta de forma mínima, não se automatiza o mínimo, nem qualidade ou valor necessários.

Há uma infinidade de histórias hipotéticas, ardilosas ou inconscientes, envolvendo ingenuidade, miopia, interesses, medo de argumentar, zelo pela estabilidade, falta de comunicação, não saber ouvir, vício em protagonismo individual e suas benesses no modelo de gestão 1.0 onde fazer exatamente o que mandam gera recompensas.

Bons indicadores são alto custo de manutenção, dimensionamento absurdo de equipes de sustentação, delay entre identificação de corretivas e evolutivas até a execução e entrega delas, quando ajustes simples exigem desproporcional esforço, novos projetos comprometidos em um ciclo viciosos de legados e deficiências coisas do passado.

Em muitos casos as empresas sequer fazem esta ilação CAPEX += OPEX, como se uma nada tivesse a ver com a outra … mas estes impasses não sobrevivem a um bom estudo de cadeia de valor. Rasgar dinheiro até é possível em tempos de bonança, mas na crise eles estarão tão imersos em soluções mal construídas que sua OPEX irá cobrar o preço.

593861c6-2213-457e-aece-17e588847be7

É fácil ser perdulário e inconsequente durante a bonança, complicado é olhar para trás e perceber que milhões desperdiçados no passado estão fazendo falta. Na hora do aperto é possível reduzir a CAPEX, reduzir sua capacidade em evoluir, mas impossível reduzir uma OPEX contaminada sem comprometer a operação, o cliente e sua imagem.

Há algo tão ruim quanto o alto custo evitável de OPEX, é quando CAPEX gera novas CAPEX, quando a cada par de anos temos que reconstruir soluções mal feitas, que acaba virando uma colcha de retalhos e exige reconstrução. Um projeto que não atende a real necessidade, um produto mal feito que não pôde ser escalado ou evoluído.

Planejamento ágil, sinérgico, ciclos iterativo-incrementais-articulados, em camadas, com boas práticas de engenharia de software, testes automatizados, devops, com equipes auto-organizadas pesando cada decisão quanto ao ponto de equilíbrio entre qualidade e valor para o negócio, geram também valor no médio e longo prazos às partes.

Nosso trabalho encarece ou mitiga a equação CAPEX += OPEX, cada decisão tomada durante um projeto irá tender a uma OPEX mais alta ou mais baixa. As decisões em um projeto com CAPEX bem dimensionada e racional pode levar a uma OPEX recorrente como no cenário #1, #2, #3 ou #4 … isto pode ser uma escolha consciente ou inconsciente.

A pergunta é: Nossas decisões estão economizando tempo ou custo ou mesmo escopo e gerando uma OPEX #1? A brincadeira que faço em meus cursos é: quem ligaria para o diretor presidente da empresa e argumentaria caso isso tornasse-se explícito? Na maior parte das vezes, líderes diriam que não tinha a menor ideia que nossas decisões levavam a tamanho impacto … afinal, no Lean, GEMBA tem direitos e deveres, a responsabilidade de argumentar, advertir sobre a OPEX, por incrível que pareça, também é nossa.

O tom deste post é provocativo, precisamos compreender o oportunismo na Teoria da Agência, o mimetismo na Teoria Institucional, sócio-técnica, trilogia de Juran, capacidade absortiva, contingencial, GC no modelo SECI e de exploitation x exploration, acredito muito em entender Teorias da psicologia e sociologia que tanto nos envolvem e citam, dá uma olhada no eBook “sobre os ombros de gigantes“.

0

Acredite, documentação é muito mais que as tais histórias

|

Acredito muito além das sábias palavras do Neil Ford, keynote no Agile Brazil de 2012, pois temos dois tipos de usuários em cada projeto, aquele óbvio, que utilizará e se beneficiará do produto entregue, mas também há um usuário oculto, aquele que dará manutenção, sustentabilidade, continuidade no que construímos, podendo até ser (feliz ou infelizmente) nós mesmos.

Como Agile Coach, consultor ou professor, insisto na necessidade de distinguir o romantismo de muitos livros e artigos de agilistas da realidade ou momentuum de sua empresa, área, equipe, tecnologia. Enquanto evoluímos no quesito de excelência em engenharia de software, devemos ter clareza do custo x benefício relativo a aceleração e redução do processo e custo de sustentação.

A tempo, a solução não é aquela encontrada pela maioria absoluta das empresa, que mascaram a sua ineficiência e péssimas práticas de desenvolvimento voltadas ao imediatismo da entrega a qualquer custo. Gerar uma alta OPEX recorrente para ter uma CAPEX reduzida amplia uma percepção equivocada de ROI, mas é fogo amigo, equivocado e inaceitável.

CAPEX (expenditure) ~ despesas ou investimentos em bens de capital; despesas de capital; aquisições. OPEX (operational expenditure) refere-se às despesas operacionais, recorrentes, continuadas.

Tenho uma extensão à Teoria da Agência, ou você está trabalhando para ficar amadoramente bem na foto e ser promovido ou tem a responsabilidade e transparência de um profissional? A entrega de hoje está gerando mais um legado a ser mantido com doses maciças de custos recorrentes ou tem baixo custo de operação por ter sido corretamente construído e documentado?

O volume reduz-se conforme a evolução de sua excelência em engenharia de software, você segue DDD, componentiza, usa BDD, especifica e automatiza por exemplos, constrói código limpo, segue boas práticas de desenvolvimento na sua arquitetura e plataforma, automação de testes e integração contínua.

Aos poucos a documentação vai se integrando ao ambiente, projeto e produto, mas não é mágico, não só porque sempre teremos registros importantes a fazer, mas porque muitos leem em um artigo que documentação é do mal e sem ter o menor critério ou escrúpulos, passam a defender um go horse documental e tem a desfaçatez de citar grandes nomes que relatam projetos de excelência …

1. Pré-game

Acredito no valor da existência de conceitos como Funil de ideias, Gestão de portfólio, programas e projetos, comitês gestores. Grandes empresas não podem prescindir disso, tanto quanto contam com os préstimos de uma governança corporativa, governança de TI, PMO, gerentes de projetos ou papel preocupado na transversalidade, em aquisições, alocações, indicadores gerenciais.

Todo o tempo e processo existente antes do projeto iniciar sua etapa de execução ou desenvolvimento é conhecido como pré-game, ideias, discussões, submissões, descartes e aprovações, culminando no planejamento que habilita a fase seguinte de game, composta por sprints, especificação, desenvolvimento, validação e entregas. Eu posso oferecer um mix flexível, mas consistente de planejamento:

1.1. Project Model Canvas – Eu utilizo para a explicitação das informações básicas coletadas, um Termo de Abertura visual em uma folha grande e postits contendo o porque o projeto é necessário, o que ele é em sua essência, quem se envolverá e percepções sobre como será planejado, quando e quanto custará. Chamo a atenção para premissas, riscos, restrições e expectativas;

1.2. Elevator Statement – Um ótimo aquecimento, uma abstrair e entender justificativa, quem são os clientes, qual o desafio, problema ou oportunidade, que tipo de solução imaginamos, qual o valor de negócio esperado, o que é utilizado hoje para atender esta necessidade e quais os diferenciais para que o cliente e usuário deixe a solução atual e apoie e use a nova;

1.3. Personas – Quem são os atores envolvidos, seus perfis, necessidades e objetivos. Caso a caso, de 0 a 100, posso apenas caracterizá-los até utilizar de Value Proposition Canvas para identificar seus interesses, dores e expectativas de ganhos. Uma técnica dedicada a gerar empatia, tentar ver pelos olhos de cada parte envolvida, antecipando percepções de ganhos e perdas;

1.4. Customer Journey Map – Uso variações simplificadas desta técnica de mapeamento, convergente a uma User Story Mapping, para entendermos os fluxos de atividades necessárias para as principais jornadas dos usuários da solução em estudo. Cada jornada, passos manuais ou informatizados. Queremos entender o passo-a-passo das personas, identificar funcionalidades do produto;

1.5. Scrum SetUp Canvas – Artefato proposto para explicitar entendimento, combinações sobre tecnologia e metodologia, necessidades prévias/recorrentes a serem consideradas para efeito de modelagem, planejamento, execução ou entrega. Qual a composição de equipe, mapeamento de tecnologia, boas práticas necessárias, métricas, DoR e DoD, atividades e reservas para start e velocidade;

1.6. Release Plan – É a combinação de diferentes técnicas para o planejamento, usando técnicas de estimativa e capacidade baseadas em valor e cronologia. Ao final teremos metas iniciais para cada sprint em relação a construção do produto. Conceitos como Minimo Produto Viável, histórias do usuário e histórias técnicas, culminando com o product backlog, uma lista priorizada e planejada;

2. Game | Sprints | Construção

A construção de software gera produtos e soluções que se perpetuam por muitos anos, décadas, conheço soluções construídas nas décadas de 80 e 90 que ainda hoje sustentam negócios complexos e críticos com sucesso. A maioria delas possui uma documentação excessiva e abrangente, defasada e inevitavelmente comprometida, a psicologia explica, frente a centenas de páginas a maioria acaba rolando e enrolando e fugindo de se atolar e dedicar dias da semana só a isso.

O segredo não é se amotinar, dizer que documentação é do mal, que ela é inútil, porque inútil é o exagero, redundância, complexidade, dificuldade. Como tudo na vida, o equilíbrio é o ideal e em agilidade as retrospectivas precisam fazer seu trabalho, identificar desperdícios e gargalos (Lean), gerar atitude, proposição de melhorias, sempre baseado em fatos e não em paixões e idealizações.

2.1. Para o DoR (Definition Of Ready):

Importante, o registro documental do nosso DoR é rico demais para não receber alguma atenção, talvez um grupo de trabalho que defina o que, como e onde. A documentação de funcionalidades deve ter esta orientação, uma árvore racional que permita rapidamente localizá-la, a orientação para sprints é temporária, a orientação funcional é permanente e deve deter informações cumulativas úteis.

2.1.1. User Stories – Narrativa e critérios de aceite, incentivando o uso de notações. Como <quem><o que><porque> para a narrativa e <dado que><quando><então> para critérios, que representarão de forma atômica diferentes regras, como as de negócio e integração. Uma linha para cada, ao invés de parágrafos embaralhados com várias regras, preferencialmente seguindo BDD.

user stories - sebastien frechina

2.1.2. Protótipos com explicações – Via de regra, na absoluta maioria dos projetos de que participo, materializando a necessidade, exponenciando o papel de um bom UX (user experience), a oportunidade de termos o desenho das telas com diferentes características de navegação e usabilidade, enxuta, simples e objetiva, que norteará de forma efetiva o desenvolvimento melhor possível;

2.1.3. Documento complementar – Diferentes empresas chamam de diferentes nomes, mas é um documento que explicita questões desde regras de integração, SEO, funcionais, alertas ou lembretes que registram questões intrínsecas que poderão gerar problemas futuros se não forem registradas. A regra é bem simples, escreva somente o que precisa escrever, o melhor documento é aquele curto, que explica o que se desconhece, evite explicar o óbvio e já acordado, conhecido (*);

(*) há quem coloque estas informações e regras complementares no mesmo documento da User Story, inclusive o protótipo, e sai por ai dizendo que só usa a User Story e é suficiente … mas só porque está tudo junto não quer dizer que é uma coisa só.

2.1.4. Cenário(s) de testes – Para mim, e é assim que conduzo em todas as empresas por onde passo, a construção pelo menos do cenário principal de testes é essencial. Este cenário fazer parte do DoR é um importante insumo para os desenvolvedores, que os revisarão antes de liberarem a funcionalidade para testes e homologação. Para o DoR eu recomendo garantir o cenário principal, o SQA ou tester pode trabalhar ou não depois os cenários alternativos a seguir;

2.2. Para DoD (Definition Of Done):

2.2.1. Código auto-explicado – Seguir boas práticas de engenharia de software, potencializada por conceitos básicos de aprimoramento do código gerado como paterns, pair programming, code review em suas diferentes formas. O código gerado por equipes ágeis e conscientes de tudo o que falei acima, esforçam-se para gerar código limpo, legível, componentizado, boa OOP;

2.2.2. Testes automatizados – O uso de boas práticas como BDD com o uso de ferramentas para geração de testes, TDD ou pelo menos testes unitários, testes funcionais. Todas estas boas práticas geram informações e conhecimento rastreável e seguro, vivo, que se mantém atualizado sempre. Bem feitos são um manual dinãmico e explicativo orientado a comportamento e engenharia;

2.2.3. Versionamento e integração contínua – A ideia é seguir uma boa arquitetura e engenharia de software, de forma que crie uma matriz e árvore passível facilmente de ser conhecida a partir de sua navegação. O uso de boas ferramentas integradas geram baixo custo de assimilação, facilita troca de responsáveis, acelera novos integrantes, pesquisas e mesmo refatoração;

2.2.4. Gestão de configuração – É uma prerrogativa inalienável a qualquer equipe, na minha opinião quaisquer scripts ou ações relacionadas a promoção daquilo que está sendo feito carece registro, aglutinação e versionamento. Algumas empresas de diferentes tamanhos deixa esta atribuição a tarefas manuais e pessoais, um erro que gera riscos e impede agilidade em ocorrências;

2.2.5. Métricas, indicadores e Status Report – O uso de boas práticas em métricas também envolvem métricas técnicas e indicadores, que devem ser escolhidos com cuidado, como as taxas de cobertura citadas acima, mas também de softwares responsáveis pelos builds e integração contínua, SONAR, a maioria são automatizadas a partir de scripts e mapas apresentados nas Sprints Review, acompanhando entregas e seus status report.

Cada um dos itens acima em teoria foram construídos dentro do próprio processo e mantidos atualizados, após o projeto encerrado é preciso mantê-los vivos, o que demanda mínimo esforço, quer em uma ferramenta ALM robusta, sharepoint, confluence, na dúvida se isso é possível, me manda uma msg …

Manual – Amaldiçoado por muitos, mas ainda úteis em casos específicos como software de prateleira, quer manuais físicos ou virtuais, conforme negócio. As vezes na forma de uma apresentação para replicação de treinamentos, as vezes vídeos, esporadicamente manuais em pdf, seguidamente virtuais, acessíveis durante a navegação, sensíveis a contexto. Pelo menos um FAQuizinho rola.

0

Se fossemos uma lavanderia, poderia ser uma lavanderia SCRUM

|

O blog http://cartoontester.blogspot.com.br não tem novos posts desde 2014, tem um traço muito próprio, mas eu tenho paixão pelo diagrama abaixo, alegoria ao método SCRUM caso nosso backlog fosse um enorme cesto de roupa suja. A beleza da simplicidade, impossível não entender o básico do SCRUM com ela.

É possível discernir facilmente cada etapa, inclusive é possível entender o que é valor, a relevância de um bom Release Plan, o que é o Selected Sprint Backlog, o próprio Sprint backlog, o conceito de sprint, a review e retrospectiva, até o pacote potencialmente entregável, daria para reescrever o guide de forma bem divertida.

Nada disso está no blog do Andy Glover (talvez parente do Danny), mas a primeira vez que olhei para essa alegoria, diagramada como abaixo, foi amor a primeira vista … todos os conceitos de timeboxes e artefatos pulam na frente, muito legal!

Poderia traçar analogia a N situações, acho que até meus avós entenderiam o que é esse tal de SCRUM, backlog, sprint, para ilustrar escolhi um cenário bem simples:

Pré-game: nosso PO chega na lavanderia SCRUM com um imeeeeenso cesto de roupa suja, mostra para a equipe e pede um planejamento para estimar o custo. O cesto é muito grande e a galera pergunta para o PO o que ele tinha ali, qual sua necessidade e expectativas, permitindo a equipe planejar e combinar o projeto.

Com o Scrum Setup Canvas eles percebem que precisarão de uma máquina de lavar, outra de secar e uma bancada de passar, dimensionamento de equipe, exigências de qualidade do serviço, pontos de atenção, cuidados, etc. Estimam que precisarão provavelmente 3 (três) sprint (rodadas na máquinas de lavar, secar e passar), mais 1 (um) de buffer na eventualidade de precisar de sete, pois dependendo do tamanho e peso das toalhas talvez seis fosse pouco.

O nosso PO diz que precisa para a primeira sprint de pelo menos uma toalha grande, pois está sem nenhuma e tem que tomar um banho para ir trabalhar e que até a segunda precisará de determinada calça de veludo, uma camisa azul e roupa de baixo para usar, determinando que para o terceiro precisaria de um smoking completo e roupa de baixo, meias pretas. De posse das informações a equipe planejou os itens a cada rodada de forma a atender as necessidades do cliente.

Ao final, está definido o nosso product backlog, entendido, priorizado, MVP, planejado em sprints, permitindo à equipe começar a trabalhar no primeiro sprint.

Sprint 1 – A equipe realiza o primeiro sprint, seguindo a prioridade do cliente, realizando cada máquina e serviços, mantendo o cliente informado do andamento e tendência. O cliente pôde passar no horário combinado e avalia o trabalho executado, comentando que esperava mais da dobradura de uma camisa, feedback depois discutido entre a equipe para que as próximas fiquem melhor.

Sprint 2 – O PO propõe alterar um pouco o sprint backlog, apontando outra calça como prioridade e incluindo mais uma toalha pequena que trouxe, mas que a equipe acredita que não impacta na previsão e por já ter entregue a toalha grande, avaliam a tendência e avisam o cliente que provavelmente não precisará do buffer. A entrega se confirma e o cliente elogia que a nova dobradura da camisa está muito melhor e a calça de brim escolhida será melhor para seu compromisso.

Sprint 3 – A cada sprint a equipe confirma com o cliente a priorização e condições, executa, entrega e ao final discute os feedbacks e percepções variadas de ocorrências. Já conhecem o cliente e estabelece-se uma relação de confiança, quer pela transparência, pela confirmação, parceria e resultados.

Quer tentar? Fecha os olhos e faça seu story board mental do projeto SCRUM da sua lavanderia com o seu cliente … acho que a galera do Savana Scrum vai abrir uma lavanderia na selva e vou postar algumas tirinhas das suas aventuras  \o/

0

No século XXI, nós humanos somos a Lei de Moore e nos reinventamos a cada 18 meses

|

Está na hora de colocar a Lei de Moore e profissionais T Shape em foco: Qual a taxa de crescimento evolutivo que um profissional imprime em sua carreira de TI no século XXI? Nos reinventamos a cada dezoito meses trabalhando em curtos ciclos iterativo-incrementais-articulados, sprints quinzenais, reuniões diárias, exercitando senso de equipe, gestão de conhecimento e capital intelectual coletivo.

A lei de Moore foi cunhada por um presidente da Intel, em 1965 Gordon Moore afirmou que o poder médio de processamento dos computadores dobraria a cada 18 meses. Quem disse foi o presidente da maior empresa de bolachas do mundo, aquelas finas fatias de cristal de silício usado para fazer microchips.

No século XXI deixamos de investir só em Hard Skills e passamos a valorizar cada vez mais Soft skills, um tão importante quanto o outro, ambos exigindo esforço cognitivo, mas passamos a dar especial valor a aspectos sociais, comportamentais, habilidades, atitudes, além apenas do conhecimento técnico.

Minha provocação é que um profissional de TI do século XXI se reinventa a cada 18 meses tanto quanto processadores dobravam no século XX. Não mudamos tudo nem dobramos, mas evoluímos hard e soft skills, evoluímos a forma como fazemos as coisas, profissionais do conhecimento, século XXI.

Um bom desenvolvedor Java, Dot Net ou mobile, por exemplo, após um ano e meio olhará para trás e descobrirá que novos métodos, frameworks, técnicas, conceitos individuais, coletivos ou ambientais terão sido absorvidos. É inevitável, há centenas de boas práticas e tecnologias a nosso alcance e aos poucos não serve mais fazer funcionar o que é pedido, é preciso fazer certo a coisa certa.

Recordar é viver!

Em trinta anos de mercado, vi muitos profissionais saindo de desenvolvimento procedural para OOP, de client-server para a plataforma web, de builds monolíticos para orientação a serviços e agora microserviços, no mundo java web por exemplo tivemos que aprender coisas novas no máximo a cada ano.

Se sacudirmos aleatoriamente a memória entre 2008 até hoje, vi profissionais aprendendo e usando, html, javascript, ajax, java, JPA, EJB, oracle, spring, primefaces, JSF, hibernate, widgets, bootstrap, junit, glassfish, angular, web sockets, js nodes, lucene, jenkins, mongo, … são dezenas de siglas e tecnologias.

Em documentação vimos a galera sair da UML e seus diagramas para novos conceitos de documentação viva, user stories e critérios de aceitação, passando por BDD e mesclando tudo isso com princípios, novas metodologias e boas práticas ágeis, design thinking, lean startup, business model generation, …

Curva normal

Na virada de século tínhamos a maioria dos profissionais ainda apegados a uma tecnologia como base de sua carreira, desde o Cobol ao Java, de Oracle Forms ao Delphi. O início do século XXI forçou um grande reposicionamento tecnológico, o bug do milênio fez com que as grandes organizações refizessem soluções antigas e adotassem melhores práticas metodológicas e tecnológicas.

De lá para cá, todos nós de TI, desde a gestão de projetos, desenvolvimento e operações vem passando por um processo de reinvenção, boas práticas ágeis da década de 80 e 90 passaram a ser vistas como um caminho a ser seguido, não só técnicas oriundas do XP, TDD, Kanban, Scrum, DevOps, mas resgate de OOP, DDD, BDD, design e qualidade ganharam valor além da funcionalidade.

Será que já construímos uma Curva Normal centrada nestes pressupostos ou será que sou eu um privilegiado por interagir com profissionais engajados em uma revolução permanente? Profissionais que já entenderam e tem a oportunidade de mudar, personificam o conceito de capacidade absortiva e T Shape que discuto no livro, workshop e jogo-desafio da “franquia” Toolbox 360° \o/

#1. A seguir compartilho as variáveis de um artefato criado em um estudo de 2016 sobre Capacidade Absortiva e intensidade tecnológica por Raquel Engelman, Edi Fracasso, Serje Schmidt e Hugo Muller, pesquisadores da Feevale e UFRGS:

Aq01. A busca por informações relevantes do nosso setor faz parte do dia a dia da empresa.
Aq02. Nossos gestores incentivam os funcionários a buscar informação do nosso setor.
Aq03. Nossos gestores esperam que os funcionários utilizem informações de outros setores.
As04. Em nossa empresa as ideias e conceitos são comunicados entre as diversas áreas.
As05. Nossos gestores incentivam o apoio entre as áreas da empresa para resolver problemas.
As06. Em nossa empresa há um fluxo rápido de informações entre as áreas.
As07. Nossos gestores promovem encontros periódicos entre as áreas para o intercâmbio de novos desenvolvimentos, problemas e conquistas.
Tr08. Nossos funcionários têm habilidade para estruturar e utilizar os conhecimentos adquiridos externamente.
Tr09. Nossos funcionários preparam os novos conhecimentos adquiridos externamente para outros fins e para torná-los disponíveis.
Tr10. Nossos funcionários são bem-sucedidos em articular o conhecimento existente com novas ideias.
Tr11. Nossos funcionários são capazes de aplicar os novos conhecimentos em seu trabalho.
Ex12. Nossos gestores apoiam o desenvolvimento de protótipos.
Ex13. Nossa empresa regularmente reconsidera as tecnologias utilizadas e as adapta de acordo com novos conhecimentos.
Ex14. Nossa empresa tem habilidade de trabalhar melhor quando adota novas tecnologias.

Profissionais de TI deixaram de ser focados em uma tecnologia e passaram a atuar em T ou Pí, não é só Agile, há dezenas de consistentes propostas sobre novos paradigmas baseados em gestão por competências, gestão do conhecimento, capacidade absortiva, management 3.0, já em pleno ano de 2017 é impossível manter-se alheio e insistir em individualismo e técnicos especialistas.

Você pode manter-se alheio ou em oposição a tudo isso, mas por quanto tempo? Enquanto isso, profissionais reinventam-se a cada 18 meses de forma natural, sem interrupções, seguindo a receita de aquisição, assimilação, transformação e exploração de uma capacidade que se inicia nos indivíduos, se materializam em equipes, transcendem transversalmente às organizações e permeiam o ambiente, empresas, grupos sócio-técnicos com quem interagem diariamente.

Pense nisso!

0

Carreiras e empresas equilibram-se entre kaizen e kaikaku

|

Alta performance tem a ver com domínio, já inovação tem a ver com aprendizado, quer profissionais ou empresas, é preciso equilibrar o que sabemos e o novo. Como em um Eurotunel, precisamos de uma galeria para a produção e outra para a inovação, que mesmo possuindo diferentes bitolas são interligadas por tuneis de serviço, para equalização da pressão entre elas e assim avançar continuamente.

O perfil T ou Pi proposto para profissionais do século XXI, com profundidade e domínio, mas também amplitude de conhecimento, equivale a teoria da Capacidade Absortiva – “conjunto de procedimentos e rotinas pelas quais as empresas adquirem, assimilam, transformam e exploram conhecimento para produzir uma capacidade organizacional dinâmica” (Zahra e George, 2002).

Há quem pense em inovação como sendo algo pertinente ao lançamento de novos produtos ou serviços por empresas, mas a capacidade absortiva vai além desta percepção de inovação. Perceber oportunidades de evolução, melhoria, mudanças, quer em nossas carreiras, quer em processos, trabalho, relacionamentos, produtos ou serviços, tudo isso depende de visão, criatividade, inspiração, de inovação.

Autofagia / Zona de Conforto

Sou um profissional de TI, quando entrei no curso de análise de sistemas em 1981 eu ainda não sabia de fato que teria uma vida profissional que exigiria atualização e adaptação em um ritmo atípico comparado a outras profissões. A cada ano é possível perceber novas tecnologias, hard e soft skills surgindo e mudando, entre elas eu preciso decidir constantemente por novos aprendizados e domínios.

Se Darwin fosse de TI, não precisaria ter viajado a Galápagos para concluir que a sobrevivência não é do mais forte ou mais rápido, mas daquele que se adapta. Força e agilidade servem para lhe tirar de um apuro, mas olhando para o passar dos anos, precisamos perceber quais as mudanças e oportunidades melhor nos convém ou nos exigem para nos adaptarmos a elas.

charles-darwin-quote

Profissionais que se acomodam em fazer bem feito aquilo que é pago para fazer vivem a ilusão de que sendo excelentes em determinado conhecimento, serão reconhecidos e regiamente pagos por isso. São profissionais de perfil I, satisfeitos com o que aprenderam e conquistaram, esquecendo que o mundo dá voltas, muda sem parar, novos conhecimentos, tecnologias e habilidades surgem e crescem.

Empresas conseguem liderar segmentos de mercado, agigantam-se para então apenas entrar para a história como um exemplo de falta de visão, incapacidade de se reinventar, não é porque não geraram bilionários, mas por falta desta percepção de continua evolução do mundo que não para de girar, apequenam-se e algumas até desaparecem porque alguém com menos recursos e mais visão as ultrapassa.

Kaikaku x Kaizen

Nossa vida e de nossas empresas fluem, equilibram, pendulam entre alta produtividade e inovação significativa. Enquanto em alta produtividade pode ser que pequenas melhorias e ajustes surjam, mas de tempos em tempos teremos mudanças de alto impacto. É como Kaikaku e Kaizen, o Kaizen é fazer bem o que sabemos fazer, com pequenas melhorias eventuais, para então termos o Kaikaku, que é um grande salto evolutivo.

O Kaizen é um continuo evolucionário, Kaikaku é revolucionário, sendo que o processo de melhoria quando praticado de forma consciente, orquestrada, tende a consumir cada vez menos energia e gerar melhores resultados. Não podemos esquecer o que Schein, Argyris ou Tofler preconizaram quanto ao desafio de aprender algo novo, ação que consome energia e deve ser entendida e dominada:

Exploration x Exploitation

Insisto muito a quem se interessou por este assunto, dá uma olhada no meu post de 2014 sobre uma resenha do artigo seminal de James G March de 1991 e minha interpretação – https://jorgekotickaudy.wordpress.com/2014/06/19/vale-a-pena-entender-o-exploitation-e-exploration/

exploration_exploitation
n2a03fig13

0

6ª e 7ª aula de GP na FACIN

|

Este ano foi injusto com quem ministra aulas nas sextas feiras, pois tivemos 2 feriados e uma greve geral, na qual a universidade teve a sensibilidade de não exigir presença e evitar provas ou trabalhos, posto que não haveriam ônibus, trens e o risco de movimentação urbana com bloqueios de ruas e eventual violência.

Mas após um mês sem aulas, retomamos com uma boa revisão da matéria, os grupos tiveram um tempo para relembrar seus projetos, que ainda estavam em fase de modelagem inicial das ideias. A seguir retomamos de onde paramos, de lá para cá foram duas aulas e a realização da primeira prova, com boa média.

05/05/17 – 6ª AULA DE GP

Na quinta aula tínhamos chegado até o Termo de abertura do grupo de processo de Iniciação, usando para isso o artefato de Project Model Canvas. Aqui seguimos com a apresentação dos nossos stakeholders, oportunidade para discutir empatia além da formalidade, não só quem é, mas o que sente e quer.

A abordagem da empatia, trazendo uma visão típica do Design Thinking é porque gerenciamento de projetos de software no século XXI é fazer certo a coisa certa, inicia desde o entendimento do problema, da necessidade e não da solução. Então personas, empathy canvas e value proposition canvas são sim técnicas de GP, ou seguiremos com as mesmas charges infames do século XX sobre a galera de TI:

No último slot da aula fiz uma provocação sobre a área de INTEGRAÇÃO e seus processos, sobre o Termo de abertura da aula passada, sobre o plano de gerenciamento de projetos, as características do gerenciamento de mudanças e ao final as lições aprendidas. Discutimos especialmente o Plano de Gerenciamento para que na próxima aula após a prova entrássemos direto em ESCOPO.

12/05/17 – P1 (PROVA)

Entre a sexta e a sétima aula, tivemos a P1, onde ocupei dois créditos com estudo em grupos de três e uma revisão geral da matéria – conceitos de portfólio, programa, projetos, sub-projetos, operações, tipos de estrutura organizacional, governança, PMO, os 5 grupos de processos do PMBOK, diferenças entre o GP tradicional e ágil, as 10 áreas de conhecimento/planejamento do PMBOK.

19/05/17 – 7ª AULA DE GP

A sétima aula foi muito pegada, pois após feriados, greve e prova, tínhamos muito o que fazer para colocarmos a pauta em dia. Em linhas gerais, discutimos alguns dos fundamentos mais importantes sobre planejamento de escopo:

  • desenho de processo
  • funcionalidades
  • categorias de requisitos
  • épicos e histórias
  • tarefas

O exercício realizado logo no início que começamos a discutir requisitos é o clássico planejamento de um churrasco da turma, quer no formato de uma jornada de usuário, com pacotes de trabalho e estrutura semelhante a uma WBS ou em rede. O exercício ajudou a acordar os alunos mais cansados em uma noite de sexta.

A aula foi bem prática, evoluímos bem no entendimento por cada grupo sobre as funcionalidades possíveis em cada um dos projetos, alguns discutindo a nível de requisitos, outros em épicos e histórias. A meta era um grande brainstorming para que na próxima aula tenhamos a WBS/User Story Mapping materializadas.

Faltando ainda uma hora e meia para o final, optei por um quebra gelo famoso por produzir muita adrenalina, conhecido como Kaa e Bagheera no escotismo ou Snakes como Team Building Games. Descemos do terceiro para o térreo, fiz um briefing sobre sistemas empurrados e puxados, organizei as filas, expliquei o objetivo, as regras e usei uma tira de papel de 50 cm x 15 cm como rabichos.

A adesão e empenho foi muito legal, todos voltaram à aula muito acordados e dispostos a mais uma hora para o braisntorming de escopo … a opção pelo jogo me fez postergar a dinâmica de pitchs e reconstrução, mas valeu a pena. Na próxima aula cada grupo/projeto terá 30 minutos para organizar seu escopo e apresentá-lo, permitindo que todos os outros cinco grupos possam questionar, sugerir, ajudar.

Durante a aula relembrei a charge das árvores sobre requisitos em um projeto, insisti na minha abordagem de profissionais de perfil T ou Pi, sobre nem só fazer errado a coisa certa, nem fazer certo a coisa errada, nossa meta é fazer certo a coisa certa. É entender o problema, para mapear alternativas e trabalhar a solução.

  • Pizzaria – O cliente liga e pede o tamanho, a massa, o recheio, a borda, não cabe à pizzaria ficar questionando se por acaso o pedido é inadequado, se vai sobrar, se alguém é alérgico, …
  • Médicos – O paciente não chega pedindo uma injeção de terramicina, é o médico que deve levantar dados o suficiente para diagnosticar e receitar a melhor medicação (ou não) para o momento.

Quem você é? O que você faz? Você ainda faz software como no século XX, quando o cliente dizia o diagnóstico e especificava o que queria ou você faz levantamentos, discute, levanta alternativas para só então trabalhar naquela que parece ser a melhor solução, mesmo assim receita e pede que o paciente volte dali a duas semanas após tomar a medicação para certificar-se de que esta certo?