0

Equipe, área ou papel – Inicie sabendo quem somos, o que e como fazemos

Se você é de TI, principalmente se for de desenvolvimento, há frameworks e modelos seguidos por milhares de empresas, centenas de livros, especialistas, mas por onde começar se você é de uma área sem tanta bibliografia e atenção? Na minha opinião, um canvas de auto-conhecimento é um bom ponto de partida, para uma espécie de 5W2H da sua área, equipe ou projeto – hoje e futuro!

Um exemplo de ferramenta são facilitações que fiz em 2017 com equipes de eventos, cursos, comunidade, geração de conteúdo, onde usei para inicio de trabalho sobre cada uma o “Role Model Canvas” do Christian Botta. Dei uma simplificada, adaptando a necessidade, privilegiando mais espaço e foco nas jornadas de trabalho, mas iniciando pelo mapeamento de missão, ferramentas, comunicação e restrições:

Pesquisando outras formas de analisar área, equipe ou papel, encontrei um canvas que já entrou  para a minha toolbox. Enquanto lia já visualizei a mecânica de uma discussão para chegarmos às oportunidades de mudanças que queremos. Tenho certeza que vou mexer na estrutura, mas aqui compartilho o original … mais adiante, assim que usar, compartilharei a minha reinterpretação, ok.

Design Ops Canvas – Um modelo colaborativo, focando em um papel ou área, sua liderança, clientes e fornecedores, buscando uma visão 360° dela. Ainda não usei, antecipo porque vou tirar férias e gostei demais, talvez até para uma reflexão de final de ano, útil a quem procura um trabalho diferenciado com sua equipe ou área nesta virada de ano … achei um pouco pesado, mas é simplifique conforme o foco desejado.

O preenchimento é da esquerda para a direita, de cima para baixo, no original sugere iniciar pela identificação das pessoas ou personas no circulo central, mas eu acho melhor iniciar por “O que fazemos?”, afinal, a área, equipe ou papel já existiam ou existirão independente das pessoas que ali estão neste momento …

1. O que fazemos? Qual é o nome da nossa área, o que geramos de valor, como trabalhamos, com que ferramental;

2. Quem nós somos? Quem são nossos integrantes, nossos stakeholders, parceiros, que tipo de suporte necessitamos deles e vice-versa;

3. Como nos comunicamosInterna e externamente, como geramos, compartilhamos e crescemos em informação, conhecimento e expertise;

4. Quais são nossas restrições? Como gerenciamos premissas, restrições e riscos, técnicas, tática, contingenciamento;

5. Como estamos estruturados? Aqui entra pegado mindset, auto-organização e controles, padrões, políticas e alçada;

6. Gestão? Missão, metas, cobranças, estrutura organizacional, responsabilidades e hierarquia;

7. Extras? Informações pertinentes que reconhecemos como relevantes para o nosso objetivo neste mapeamento;

Com certeza pode ser usado como um warm-up ao iniciar uma discussão sobre si mesmo, enquanto equipe, área ou projeto. O autor sugere que encontremos oportunidades no uso de cores dos postits, quer por papel ou nos pontos de atenção. É possível com certeza usar cores ou postits diferentes para indicar o AS IS e o TO BE. O original está nos links abaixo:

 

0

Receita para uma retrô colaborativa 2017 e sonhar juntos 2018

Em uma tarde, de forma lúdica e muito interativa o tempo todo, a construção de uma retrospectiva do ano de 2017 e sonhos comuns para 2018, cada sonho com proposta de ações a serem vistas como próximos passos para aquilo que queremos todos ver acontecer.

Me sinto agraciado por conhecer e interagir com tantas pessoas incríveis, uma estrada que me permite encontros e reencontros, aprendizados, oportunidades para colocar minhas crenças e convicções em cheque a cada nova interação com pessoas, em eventos, projetos, debates.

O diferencial não é a técnica, nem o material, o tamanho da árvore, o desenho dos murais, a diferença está sempre na empatia, na sinergia, nas pessoas, é o senso de time, o desejo de sonhar juntos, mesmo nas diferenças, o maior ganho é aproximar pessoas.

14:00. Abertura, com boas-vindas, alinhamento de expectativas, apresentação do programa-base, convocar a ação, se possível uma palavra do anfitrião, quer seja um diretor, gerente, sponsor, conclamar em torno de uma missão, o que nos trouxe aquele momento. Evitar ser um monólogo, interaja um tanto, cite algo, cumprimente, elogie, gere senso de grupo. No programa é bom alinhar horários e liberdades, como se necessário atender o celular para algo muito importante, há o saguão, uma forma de atribuir liberdade com responsabilidade;

14:15. Quebra-gelo natalino, uma árvore de Natal incompleta, embaixo de cada cadeira mais um ramo e um enfeite, inclusive em algumas cadeiras vazias – esse é o fato acima de qualquer outro, cada um de nós é uma pequena parte de algo maior, apenas quando todos juntos, colaborando, vendo o todo, vendo que falta algo, talvez alguém ausente, entender a sua parte, ser pró-ativo, ajudar uns aos outros, de forma positiva, construtiva, sem verdades absolutas, mas complementares;

14:40. Retrospectiva 2017, estabeleça provocações iniciais, resgate momentos, talvez algumas conquistas, mantenha aquela inquietação positiva do quebra-gelo para introduzir a técnica de brainstorming. Duas mesas grandes com muitos postits e canetões coloridos e nas quatro cabeceiras os letreiros – EU, Nossa Área/equipe, Empresa, Clientes/mercado. De forma auto-organizada, meio caótica, todos circulam pelas mesas e vão lendo os postits já propostos, podendo criar novos e votar com palitinhos, ao final dezenas de sugestões com votação;

15:15. Mural da retrospectiva 2017 será formado na sequência, ainda com a maioria em pé entorno das mesas, algo que chamamos de ponto de saturação, não espere todos sentarem, nem interrompa enquanto muitos ainda estão propondo novos postits. O mural será construído de forma que os mais votados estejam bem encima e os menos votados cada vez mais para baixo, é possível estabelecer um racional para o eixo horizontal também, como cronologia ou alçada, da esquerda para a direita. O resultado, enquanto a galera senta pode ser apresentado, quando lemos e revisamos de forma breve o quadro final … sujeito a eventual réplica e adendos;

Obs: Os duendes a esquerda embaixo indicam projetos ou ações em curso, que já geraram alguns resultados, mas há ainda muito pela frente.

16:00. Coffe-break

16:20. Quebra-gelo de identidade da tarde é o clássico jogo colaborativo dos crachás, onde cada um interagiu com pelo menos 5 ou 6 colegas para compôr sua “foto” (desenho onde cada colega contribuiu com um traço, como olhos, boca, cabela, orelhas, barba, nariz, …) e paixões (coisas que curtimos e que a maioria não sabe, podendo ser família, esporte, hobby, música, filmes, …). Aproveitamos o resultado para a galera colocar no segundo mural, o de 2018, na base de uma grande árvore de Natal onde depois colocaremos nossos sonhos para o ano que vai começar;

16:40. Sonhos e ações para 2018, na esteira do quebra-gelo dos crachás e início do mural 2018, usando a mesma técnica de brainstorming com as duas mesas grandes com postits e canetões coloridos e os letreiros – EU, Nossa Área/equipe, Empresa, Clientes/mercado. Já com a galera mais afinada com a técnica descontraída e divertida, todos circulam pelas mesas, vão propondo e lendo os postits propostos sobre sonhos e ações sugeridas para fazer eles se concretizarem, novamente com direito a votos e complementos. Os sonhos são bolas e postits pequenas cada ação;

17:20. Um grande mural dos sonhos para 2018 com aquela grande árvore de Natal é preenchido por todos com as bolas contendo os sonhos mais votados mais para cima e descendo com as menos votadas. Assim que as bolas estejam colocadas, o próprio facilitador pode ir lendo um por vez, de cima para baixo e buscando o entendimento do que é o sonho, quais as ações propostas e o quanto ele é factível ou não, faz sentido ou não, se merece estar ali ou não, … é bem fluído, vamos colando novos postits, eliminando alguns por consenso, chegando a uma construção realmente coletiva;

18:00. Encerramento, sempre é bom pedir um feedback, qual o sentimento que a galera leva dali, se atingimos algo satisfatório e o quanto desenhamos juntos algo que dependerá da ação e contribuição de todos, no final sempre uma palavra por quem quiser contribuir nas frases finais e em especial do sponsor, gestor, diretor presente com um incentivo final e desejo coletivo de Boas festas e um ótimo 2018 a todos.

Parece que foi ontem e estávamos iniciando mais um ano junto a pessoas queridas, 2017 está encerrando, 2018 se descortina com novas possibilidades, seguir em frente, ampliando ou renovando esforços e conquistas … sempre melhores que antes, aquém do que seremos um dia!

Desde já, um Feliz Natal e próspero ano novo!

0

Stop The Line – Se tiver que apertar, aperte, mas só se for o caso :)

Há uma técnica adaptada do Lean Toyota que se chama “Stop The Line”, destacando algo que já passou por todo o processo de desenvolvimento e precisa priorização de ajustes (bug, impedimento, mudança) para ser entregue e não ficar com status de “quase pronto, mas com problemas”.

Diz a lenda que na Toyota havia botões vermelhos escritos “Stop The Line”, o custo ao apertá-lo era o de parar a linha de produção com um alto custo por minuto, mas mesmo assim evitando que defeitos persistissem e gerassem um ônus ainda maior adiante.

Em projetos de software, é um selo para chamar a atenção de que algo já consumiu os recursos, mas que exige algo mais para ser considerado pronto. Se ele era mais valoroso que os demais para iniciar, provavelmente é algo de valor que precisa atenção adicional para não ficar parado.

Uma técnica com foco em entrega antecipada de valor, que assim como o WIP (work in progress), responsável por limitar o número de atividades em cada status do fluxo de trabalho, nos induz a privilegiar primeiro acabar algo iniciado ao invés de ficar empilhando semi-acabados.

Gosto muito da frase do Juan Bernabó no final do Agile Brazil de 2016 – “Esperamos que as retrospectivas façam o seu trabalho!”. Tomo a liberdade de colocar a frase logo acima de um fictício botão de “Stop The Line”, com uma matriz que sempre uso para indicar o ciclo de vida de um sprint … quase tudo tem um momento ideal:

Stop The Line é um modelo mental

Se a descrição acima faz sentido, expanda além das funcionalidades, tarefas e defeitos, use este modelo mental para tudo, uma vez planejado o Sprint Backlog, quanto maior o foco e dedicação, melhor, pois haverão imprevistos, então deixe para depois o que não faz diferença ser agora.

Uma sprint possui uma estrutura pensada para foco em valor e resultado, adaptação sempre que necessário, com apresentação e aprendizados ao final, gerando um moto-contínuo equilibrado entre liberdade e responsabilidade, cerne da auto-organização.

Tem muito a ver com Pareto, não tem receita de bolo, mas o melhor é ver o todo e priorizar aquilo que gera mais valor e aparentemente fará diferença, o restante deixe para as retrospectivas fazerem o seu trabalho (mesmo em retrôs eu não imponho a pauta, ela é do time).

Tanto o WIP quanto o STL são padrões mentais relativo a sistemas puxados que vão se construindo em um time ágil, não por poder garantir só acertos, mas principalmente saber lidar com experimentação e erros, afinal, a cada novo insight ou percepção é preciso refletir:

  • Manter o time focado durante 8 dias na sprint tem seu valor.
  • É necessário “stop the line” para discutir isso agora?
  • Se sobre critérios DoR, não dá para aguardar a Grooming?
  • Se sobre critérios DoD, não dá para aguardar a Review/Retrô?
  • Alguns impasses urgentes vão surgir, esse merece ser um deles?

Os primeiros Sprints de um Projeto

Há uma ampla gama de aprendizados, alguns ajustes em tempo real são vitais para estabelecer um patamar de confiança entre equipe, PO e stakeholders, baseado em entregas de valor e qualidade, outras questões podem esperar a retrospectiva.

Sem esquecer de Tuckman, da curva de aprendizado, de alguns sprints com riscos adicionais pertinentes a certo grau de tensão e desconhecimento do projeto, dos colegas, da tecnologia, modelo de dados, que a cada sprint vão-se mitigando e criando raízes fortes.

Ainda na minha opinião, que não vale nada, por isso é de graça, querer acelerar e garantir todos os aprendizados o mais rápido possível nos empurra para comando-controle ou tensão desnecessária, eu acredito em tempo ao tempo, equipes fortalecem-se e encontram seu ritmo.

As vezes não consigo deixar de lembrar o episódio do “Dino Da Silva Sauro” da família Dinossauro, quando assina uma TV a cabo com 150 canais … ele faz um cálculo e concluiu que a cada hora deveria assistir 24 segundos em cada canal para aproveitar ao máximo o investimento. Via de regra, menos é mais!

0

Kirkpatrick – O que seria de nós se não soubéssemos das curvas?

Há diferentes teorias e curvas que reiteradamente discuto e que nos ajudam a entender o processo cognitivo e desafio relacionado ao aprendizado, mudança e melhoria, como a Curva de Tuckman para formação de um time, hoje vou compartilhar a Curva de Kirkpatrick.

Em 1994, Donald Kirkpatrick publicou um bestseller intitulado Avaliando Programas de Treinamento, apresentando quatro estágios relacionados aos possíveis desdobramentos de um treinamento, gerando o que chamou de reação, aprendizado, comportamento e resultados.

O entendimento de Tuckman, Ebbinghaus, Kirkpatrick e outras, nos ajudam a entender antecipadamente os porquês e de posse destas informações trabalharmos desde cedo com argumentos e ações para gerar maior efetividade na formação e evolução de nossos times.

Vejo isso a cada treinamento, a curva sobre a conversão de ensino em aprendizado e sua conversão em prática, os estudos de Kirkpatrick lançam luz e nos ajudam a melhorar enquanto palestrante, instrutor, professor, facilitador e/ou coach.

Vai além da Curva de Ebbinghaus sobre nossa capacidade e limitação de retenção e assimilação, também Edgar Schein, lembrando que a mudança gera desconforto quando percebemos que deixaremos o conhecido para tentar algo novo, que ainda não dominamos.

Eu tenho uma matriz temporal de condução para qualquer treinamento, conhecida por quem me acompanha, com um pré (organizar e instigar metas), há a execução (interagir e projetar) e um pós (experimentar, persistir e melhorar), onde acrescentei a curva de Kirkpatrick:

Em seu estudo Kirkpatrick estabeleceu ranges para cada etapa, mas como agilista eu acredito que cada pessoa, imerso em times e cultura organizacional, estabelecerá um ritmo para seu grupo, conforme liderança, metodologia, maturidade, domínio, etc.

Conhecer as diferentes curvas nos ajudam a agir para torná-las mais fluidas, gerando maior retenção e conversão em resultados práticos. Mantendo a reação em seus insights, o interesse no aprendizado, a pró-atividade do comportamento e persistência até os resultados:

1- Reação é quando o aluno ou participante percebe que aquele conteúdo tem a ver com ele e que pode ser útil de alguma forma, colaborando para possíveis melhorias no seu trabalho ou a ele enquanto pessoa. Refere-se a interesse e a maioria se motiva!

2- Aprendizado é quando o aluno ou participante se mostra interessado realmente, interagindo com o instrutor e demais participantes enquanto traça cenários imaginários de uso e projeção de resultados. Diz respeito a entendimento e planejamento!

3- Comportamento é quando o aluno ou participante estabelece uma experimentação e aprendizados, permitindo-se mudar para tanto. Diz respeito a vivência e validação, exigindo engajamento e persistência!

4- Resultados é quando estabelece-se aquilo que chamamos de melhoria contínua, os resultados já são percebidos e os mesmos são valorizados. Refere-se a evolução proposta pelas artes marciais como Ju-Ha-Ri, adaptando e tirando o máximo de benefícios.

Em treinamentos é preciso instigar pessoas a serem agentes de mudança, não desistirem e serem exemplo. A psicologia afirma que todo grupo humano possui lideranças ou formadores de opinião, o tempo e o sucesso de um processo de mudança depende muito do exemplo deles.

 

1

Do A3 Report previsto à reinterpretação do Role Model Canvas

Retornei à Curitiba com o briefing de facilitar uma reunião da equipe de staff de uma associação internacional de médicos com foco em ensino, disseminação de conhecimento e melhores práticas. A primeira foi no início de 2017 e contou também com o board latino-americano.

Fui com a intenção de utilizar uma técnica de brainstorming para focar o(s) principal(is) pontos de melhoria e depois usar um A3 Report para instanciar um canvas contendo premissas, planejamento, plano de ação, comunicação e melhoria contínua, mas … chegando lá, mudei.

Estava previsto um alinhamento sobre objetivos, contexto, riscos e oportunidades no dia anterior ao evento. Não Teríamos um planejamento de projeto ou tarefas, mas focaríamos em auto-conhecimento e oportunidades de melhoria em quatro papéis e suas interdependências.

A partir de nossa conversa, me propus a utilizar para cada uma das áreas, envolvendo de dois a três profissionais, uma jornada de auto-conhecimento, reflexão e priorização, para então realizar um exercício de pontos de melhoria e priorização de ações até Janeiro de 2018.

De volta ao hotel, optei por usar um canvas alemão de modelagem de papéis, mas ajustado para focar em processos, fluxos de trabalho e suas oportunidades de melhoria. O canvas (alemão) “Role Model Canvas” foi desenvolvido por Christan Botta (abaixo um dos links, todos alemães).

Não o usei de forma literal, o adaptei a minha necessidade, mas mantive o mérito ao autor. O reinterpretei visualmente de forma a privilegiar o que era para nós mais importante, por isso reorganizei e propus uma abordagem dirigida para preenchimento e abstração, conforme segue:

1º. Missão, antes de mais nada, o que é esperado, resultados esperados, porque de sua existência;
2º. Restrições conhecidas, as principais, tendo surgido algo quanto a alçada, budget, equipe, dependências;
3º. Parcerias essenciais, internas ou externas com quem a área ou processo ou programa conta ou depende;
4º. Informação que lhes são cobradas, métricas, metas, indicadores e quem as solicita ou exige;
5º. Ferramentas, de forma a deixar claro quais são e eventual contextualização;
6º. Trabalho, principais jornadas, procedimentos, com selos de valor, oportunidade e prioridade.

Tivemos duas rodadas, uma com três grupos e depois com dois reagrupamentos. As diferentes áreas de atuação da equipe, sendo ensino, marketing, pesquisa e comunidade, também se optando por discutir um processo (ANA) e um programa específico de ensino;

Na verdade, iniciamos com uma lightning talk e objetivos esperados para o evento conforme o chair do board latino-americano, realizamos um quebra-gelo divertido remetendo a importância da interação e participação ativa de todos, para então fazer uma talk de uma hora com debates.

Durante a primeira hora fiz um overview metodológico, conceitual, debatendo algumas técnicas e métodos de trabalho baseados no Lean e Agile, com bastante interação e contribuições, inclusive relatos do uso de práticas semelhantes em eventos do board internacional.

Assim que decidiram os grupos de trabalho, a primeira rodada encerrou as 13:00, contando com uma apresentação e debate do mapeamento realizado por cada grupo, gerando muita interação, insights e cenários alternativos conforme percepções, conhecimento e vivências de cada um.

A tarde uma segunda rodada, redistribuindo os grupos para mais dois canvas e apresentações. Na sequência, um conceito de clusterização para tópicos mais relevantes, no quadro abaixo ao canvas, tivemos a manifestação dos pontos de melhorias mais relevantes por duplas ou individual.

O mais votado recebeu um exercício ilustrativo de brainstorming em grupo, mostrando o potencial de melhorias, certezas, dúvidas e suposições, concluindo com meia dúzias de ações distribuídas de hoje até Janeiro de 2018 para preparação de propostas de mudanças ao board ou mudar.

A ideai é estabelecer um novo mindset de equipe, baseado em princípios Lean e ágeis, com maior domínio sobre planejamento x execução x aprendizado x replanejamento, baseado em modelos PDCL e muita auto-organização.

Os feedbacks foram positivos, as perspectivas e expectativas são muito consistentes com a necessidade de mudança exigir tempo e esforço, não por deficiências, mas por realismo, em uma equipe que performa e é bem avaliada, introduzindo-se Lean Thinking para melhorar ainda mais.

Links relacionados:

 

2

Ao invés de perguntar sobre documentação, aprenda com ela

Que tal um Doc Journey Map, como um Customer Journey Map inspirado em 5w2h e SIPOC?

Conforme o porte da empresa, envolvem-se Governança, PMO, área de processos e representantes das equipes, trata-se de uma necessidade e responsabilidade da organização estabelecer alguns padrões e GQA necessário.

Lembra SIPOC, trabalha uma espécie de 5w2h de origem a destino de cada artefato, incluindo uma reflexão sobre custo (empenho), confiabilidade, redundância e validade, quer temporária ou permanente.

Como todos os canvas e artefatos ágeis, são experienciais, o objetivo não é seguir o roteiro, mas estabelecer uma discussão focada em desperdícios e valor, assertiva, da melhor forma possível, caso-a-caso.

Não se preocupe com o número de campos, o preenchimento é orgânico, preencher é fácil e rápido se as pessoas envolvidas estiverem presentes, promovendo um debate não sobre certo e errado, mas uma auto-avaliação, momento e necessidades.

DOC JOURNEY MAP II

Baixe o canvas acima em tamanho A3

Em startups e pequenas empresas nunca usei, nunca precisou, esta é uma técnica para grandes empresas, quando há áreas de processo, governança e PMO, pois a discussão sobre métodos ágeis sempre envolve também documentação.

Um exercício que pode gerar muita empatia e sinergia, todos buscando potencialmente passar a gerar artefatos com maior conhecimento do processo, o mínimo realmente necessário, considerando origem, destino e relevância.

Eu sempre começo pelo processo, é quase um aquecimento, de forma simplificada, garantindo sempre que seja divertido e descontraído, direto no quadro branco. O resumo é o passo-a-passo da documentação em questão, eu coloco inclusive os nomes da galera.

Artefato – Nome do artefato
GT – Grupo de trabalho
Data – Datas de discussão

Quem cria – papel ou equipe
Onde/como – ferramenta e repositório
Conteúdo/objetivo – informações
Custo/energia – Tempo e envolvimento
Redundância – Único ponto ou não

Quem usa – papel ou equipe
Quando/porque – momento e para que
Valor agregado – qual o seu valor
Validade – temporário ou permanente
Confiabilidade – é confiável, timing

Processo – fluxo simplificado de manipulação desta documentação
Meta/futuro – qual a projeção, melhoria, mudanças, novas práticas, substituição

Não tem um roteiro rígido, mas bom senso, eu uso uma folha para cada artefato utilizado ou proposto, preenchendo com postits pequenos, pelos olhos de quem faz e quem consome … estruturando um mapa de docs na parede, da esquerda para a direita representando tempo.

Uma folha para cada documento ou artefato, entre as pessoas interessadas, em um GT, não impondo certo ou errado, mas provocando uma reflexão e debate sobre cada oportunidade, construção e manutenção, custo x benefício.

No mercado tem uma variedade de artefatos e documentos, alguns bem tradicionais, alguns ágeis, muitos em transição – Visão, análise de negócio, casos de uso, ER, histórias do usuário, product backlog, BDD, protótipos, cenários de testes, …

Não é um autor que vai dizer o que é bom ou não para o momento de vocês, afinal estamos todos em transição, os livros, artigos e debates em fóruns e CoP’s ajudam a ter maior discernimento neste debate sobre o que manter, mudar, abandonar, um passo cada vez.

O campo de meta/futuro é exatamente identificar alternativas futuras para substituição ou mesmo eliminação, quem sabe boas práticas como histórias do usuário, seguindo DDD, partindo de BDD, código auto-documentado e clean code, uma boa orientação a serviços, automação de testes funcionais, etc.

Documentação é inversamente proporcional às suas boas práticas ágeis
Acredite, documentação é muito mais que as tais histórias do usuário

2

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.