0

II TecnoTalks sobre Toolbox no RH

Uma edição com profissionais de RH, consultores de RH e profissionais de TI com interesse por questões de cultura, estratégia, tática e técnicas relativas a área de RH ou simplesmente Pessoas. Começamos relembrando as cinco categorias e disciplinas discutidas na primeira edição em 2018.

Logo mais, o papo foi-se desenrolando a partir da apresentação de cada um e suas percepções e desafios de mudança, profissionais de consultorias, grandes empresas e startups, debatendo os próximos passos na disseminação de princípios e métodos ágeis além da TI, papéis, protagonismo, por onde começar ou como potencializar.

Citaram e convergiram ao lembrar de J.P.Coutinho e do “Manifesto Ágil do RH” (link), debatendo o futuro desta área e seus papéis como HRBP em empresas que já praticam Agile na TI com equipe auto-organizadas, onde cada vez mais disseminam suas técnicas e boas práticas às outras áreas.

O quanto estas outras áreas procuram a TI e consultores de TI para ajudar nesta transformação, além de tantas boas práticas sobre gestão do conhecimento, relacionamento com o mercado, universidades, eventos, feedbacks 360°, contratação e demissões orientadas a seu contexto, protagonizadas pelos próprios times.

Falamos várias vezes sobre OKR, people analytics, avaliação continuada e distribuida, sobre management 3.0, mentorias e Agile Coachs. A necessidade de orquestração em mudanças organizacionais e culturais que demandam muito tempo, anos, que para dar certo é preciso dedicar tempo, liberando tempo daquilo que pode ser automatizado.

Para fazer isso acontecer é preciso desapegar do mindset das áreas de RH do século XX, adaptando-se aos princípios e nova estrutura organizacional proposta, com redes, auto-organização, descentralização, onde muitas das responsabilidades e padrões ditados pelo RH agora são mais flexíveis, conduzidos e adaptados pelas pontas.

Inexiste consenso ou receita, mas a premissa era buscar a sinergia de experiências e vivências de forma a proporcionar a cada profissional ali presente alguns insights aderetes a sua realidade, conforme exposto por ele mesmo … uma espécie de mentoria coletiva TecnoTalker \o/

Esse foi o objetivo acordado no início, trocas de conhecimentos e percepções em cada cenário apresentado, alguns iniciando, outros em meio a uma jornada de transformação e consultores que vivenciam isso quase que diariamente … muitos nomes foram lembrados, citados, vários estava presentes na primeira edição.

0

Planejamento – Quase sempre as preliminares são cruciais

Há alguns anos eu propus e uso de um canvas para pré-inception, entretanto, não é só em software que esta abordagem faz sentido, isso vale para a vida. O canvas em questão é o SCRUM SETUP CANVAS, destinado a materializar, debater ou refletir sobre questões básicas relacionadas ao planejamento de um software corporativo.

Há exceções, reunir um grupo de pessoas para discutir um projeto de software em uma organização pode seguir um viés de inovação tal que não temos nem ideia de qual a tecnologia, quem serão as pessoas envolvidas, metodologia, bem como arquitetura ou plataforma … mas essa não é a regra, nem para tecnologia, nem boas práticas.

Em 95% dos projetos que me envolvo há um domínio e tecnologia implícita, usualmente há uma equipe envolvida, há padrões e limitações. Em sistemas financeiro, de RH, logística, varejo, entre outros, a inovação via de regra está nas histórias, nas características, ergonomia, usabilidade, etc.

A tempo, clique no link para acessar o manual com o canvas em A3 para impressão – https://jorgeaudy.com/manual-ssc-scrum-setup-canvas-ed-5/

A Mayra de Souza Machado incrementou alguns campos adicionais relacionados a outras combinações, como times remotos, ajustado a realidade do ZAP em https://medium.com/guma-rs/alinhamento-teamrules-facilita%C3%A7%C3%A3o-agreements-teams-canvas-acordos-do-time-cee832b65ba3

Nem sempre preencho todos os campos, as vezes alguns campos possuem seu próprio quadro ou canvas, como o Elevator Stetement ou um Mapa de Tecnologia, mas a intenção aqui é registrar o contexto metodológico e tecnológico em que o projeto transcorrerá.

Arquitetura e tecnologia

Um amigo meu defende que não vale a pena perder tempo mapeando a arquitetura e tecnologia no início, diz que isso deve acontecer conforme o projeto anda e decisões vão sendo tomadas, mas a minha experiência em projetos de software é que poderão haver experimentos, mas sempre temos um mapa amplamente conhecido.

Digo isso, porque frameworks, bibliotecas, linguagem, automação, boas práticas e técnicas influenciam em tudo, desde expectativas, estimativas até a aceitação, algumas vezes já prevendo possíveis variações entre MVP’s e Releases. Normalmente é rápido e muito elucidativo a todos os envolvidos – riscos e oportunidades.

Planejamento Estratégico ou Tático

Sempre que posso, saber quem somos é fundamental, já conduzi várias dinâmicas de planejamento estratégico, portfólio, programas, meu primeiro passo sempre é mapear quem são as partes envolvidas, seu dimensionamento e ao que estão dedicados, se possível, com um mapa de dedicação e portfólio.

Eu chamo estas prévias de aquecimento de sinapses, conheço muita gente que acha que ser inovador é partir de uma página em branco, mas estes casos sempre demoram mais para chegar no ponto de largada e com frequência esquecem coisas importantes que inviabilizarão suas conclusões.

O mais surpreendente e positivo em um bom briefing e combinações sobre o contexto em que estaremos planejando algo é que com frequancia não há um consenso fácil e alguns termos precisam ser pactuados, as vezes, alguém tem que ceder ou decidir para que uma só percepção seja estabelecida coletivamente.

Desperdício

Planejar a revelia de quem somos, o que somos, nossas competências e deficiências, é sinônimo de querer não perder tempo alinhando percepções essenciais, expondo conhecimentos e domínios relevantes, normalmente isso é sinônimo de engavetamento, porque na hora de fazer, surgem questões que foram deixadas de lado.

Para qualquer tipo de planejamento, quer estratégico, tático ou técnico, auto-conhecimento e alinhamento de quem somos e quem queremos ser é fundamental, porque gera uma percepção de realidade e desafios, pontos de atenção e viabilidade. O maior valor é o debate, resultando em um pacto em torno de termos de contexto.

Por exemplo, em Design Thinking se diz que um MVP (Minimum Viable Product) é a intersecção entre algo que é Desejável, Factível e Viável. Logo, é de se pressupor ser importante um bom mapeamento e auto-conhecimento para balizar o que é factível e o que é viável, ou pelo menos o que não é e exigirá mais recursos ou tempo.

0

Uma alegoria livre sobre valor agregado para pensar nosso 2019

Equipes engajadas e auto-organizadas, ágeis, tem muito mais a contribuir além de (apenas) fazer aquilo que lhe solicitam (ordenam). Em equipes ágeis, valor agregado real pressupõe o entendimento e engajamento ao problema, no valor que uma solução representa para alguém em seu contexto, sem desperdício.

Sem este modelo mental ou paradigma aplicado, agilizamos o óbvio de forma tão aleatória quanto no passado, as vezes o erro, as vezes o acerto, mas jamais atingiremos a sinergia de nosso potencial. Trabalhando juntos, somando conhecimentos sempre seremos mais fortes que cada uma das partes.

Valor agregado não é uma receita de bolo, cada grupo de pessoas, empresa, contexto tecnológico, deve buscar as suas competências essenciais, hard e soft skills, criatividade, empreendedorismo, com um que de inovação, superação e reconhecimento.

Valor Agregado na cadeia produtiva

Quero partir deste conceito elementar para falar de pessoas, equipes e empresas. Valor agregado é o valor adicional que adquire um bem ou serviço ao serem transformados durante o processo produtivo. Em uma empresa, é a contribuição adicional de um recurso, atividade ou processo a um produto ou serviço.

Uma equipe ou profissionais que apenas cumprem ordens, como se militares fossem, equivaleria a plantar e vender o cacau in natura. Entretanto, quanto mais houver sinergia, pelo somatório de vida, experiências, paixões, interesses comuns versus objetivos, maior o valor agregado, equivalendo a processar, servir, encantar.

O erro nesta abordagem é fazê-lo sem ter um driver por valor iterativo-incremental-articulado, um passo de cada vez, racional e responsável. Trabalhar orientado a MVP (Minimum Viable Product), pequenas releases, seguindo o conceito de programas ou small project philosophy (Standish Group).

Valor agregado em equipes ágeis

Independente da metodologia ou nomeclatura, a base diz respeito a sinergia, alguns chamariam filosoficamente de egrégora. É como se denomina a força espiritual criada a partir da soma de energias coletivas, quando um grupo alia-se e congrega para gerar resultados além do racional, além do óbvio.

Empatia e dedicação de todos em relação ao ciclo de vida completo, desde o cliente que origina uma necessidade, passando por todos os envolvidos direta e indiretamente para que cada vivência pessoal e expertise somem-se gerando um substrato que racionalize cada passo na busca daquilo que precisa ser feito.

Para isto, é preciso haver clareza em um denominador comum, em equilibrio e equidade, onde todos percebem seu valor enquanto parte de algo maior que apenas pedidos, hierarquia, ordens e tarefas bem executadas. Não a toa o mindset ágil baseado em valor, empatia, sinergia e auto-organização está na moda.

O case de um presente de Natal

A Luisa Audy (21) está fazendo um curso de cinema no Canadá, venho passar 15 dias de férias conosco e resolvemos comemorar indo ao Natal Luz em Gramado. Desde o início ela queria comprar umas lembrancinhas de suas férias para os seus professores e pensava em chocolate de Gramado.

Exercitando empatia com seus professores, não só levou uma lembrança, mas ofereceu uma experiência. Ela poderia ter só levado chocolate, mas contou uma história criando um vínculo entre eles, apresentando Gramado, seus chocolates artesanais, o festival de cinema, o kikito e o prêmio oferecido pelo Canadá em 2017.

Junto de bombons, trufas e um Kikito de chocolate, criou uma tirinha relatando sua origem geográfica, as hortências, o chocolate artesanal, o festival de cinema latino-americano que premia desde 1973, a aproximação com o Canadá, com a VanArts e a TFS, resignificando aquela estatuetinha de chocolate que ganhariam.

Isso é valor agregado, é incluir paixão à algo que poderia ter sido apenas chocolate, neste caso mantendo tempo, custo e escopo, mas transcendendo e oferecendo uma experiência nova, agregando conhecimento, compartilhando vivência, um storytelling que transforma algo simples e objetivo em pura magia.

Ponto para reflexão para 2019

Ao entender um problema, negócio, cliente, desafio, carreira, não temos mais como missão só fazer o que foi solicitado, mas gerar uma experiência que traduza algo singular, o somatório do conhecimento de vida de um grupo de pessoas envolvidas, que oferecerão mais que “chocolate”, elas oferecerão uma “experiência de valor”.

Afora isso, no case acima apresentado, rolou paixão, viabilidade técnica, entendimento do que seria o mínimo produto viável, um protótipo, confecção, parceria na montagem, tudo isso em não mais que algumas horas espalhadas em alguns dias lastreado em um propósito singular … presentear seus professores como sinal de estima.

Vem aí 2019, qual é o seu propósito, como e com quem você quer encantar, não só o cliente, mas o mundo ao seu redor?

0

Seleção e ranking like “Bolsa de Valores”

Uma vez constituido um painel com todas as ideias ou projetos, é possível usar uma técnica chamada “bolsa de valores” para priorização, com lances investidos em cada ideias, ítens de um portfólio, desafios, gerando nosso índice “Dow Jones”.

A técnica é muito simples, prepare bloquinhos de postits com valores monetários, número compatível ao número de ítens, eu já rodei com 15 “notas” (postits), de forma que totalizavam R$40.000,00 seguindo fibonacci em centenas (1, 2, 3, 5 e 8 x 1000).

A tempo, podem ser notas de 1, 2, 3, 5 e 8, mas aí quebra a mágica do fundo de cena com valores finais de milhares de reais investidos. Outra observação relevante, é chamar a atenção de que o número de notas deve ser compatível ao número de ítens, se forem 5 ou 6, pode ser apenas uma nota de cada valor por pessoa 🙂

Eu, para facilitar a visualização e controle pessoal de seus investimentos, uso uma cor para cada investidor, uso uma letra/símbolo diferente para cada 15 notas de cada participante e uma só cor para cada valor de nota. O motivo é que cada um precisa se achar onde investiu e as vezes remanejar.

Qtde Notas Total
5 $1,000.00 $5,000.00
4 $2,000.00 $8,000.00
3 $3,000.00 $9,000.00
2 $5,000.00 $10,000.00
1 $8,000.00 $8,000.00
15 $40,000.00

A dinâmica é cada empreendedor social, stakeholders, colegas, amigos, alunos ou executivos, recebam 15 postits pequenos, cada um com um valor estampado de R$1000, R$2000, R$3000, R$5000 e R$8000, podendo investir seu dinheiro a seu critério entre os ítens em discussão.

Na parede, uso uma folha A5 ou A4 para cada ítem, detalhando informações ou critérios comparativos, pessoalmente eu prefiro a seleção de campos do Lean Project Canvas, aqueles que mais nos ajudam na comparação, mas tem GUT, RAB, ANSOFF, etc.

A parede fica com várias folhas, cada uma com uma ideia ou ítem, mais informações adicionais, como solução atual, tendência, grandeza para valor e custo, volume ou comparativo, benefício, mercado, … cada participante colará postits (seu dinheiro) nas folhas.

Após concluir a rodada de distribuição de investimentos, montamos o nosso índice “Dow Jones” somando os investimentos em cada um e gerando assim o ranking daqueles que mais os participantes investiriam, seguido de um debate sobre o resultado (ranking) gerado.

  1. Prepare antecipadamento os valores em postits pequenos;
  2. São 15 postits por pessoa – 5×100, 4×200, 3×300, 2×500 e 1×800;
  3. Pode ser uma cor para cada valor ou cor/símbolo por participante;
  4. Os ítens disponíveis para investimento devem estar na parede;
  5. Cada integrante distribui seus postits (valores) a seu critério;
  6. Após 15 minutos (*) todos ajudam a totalizar os valores de ítens;
  7. Após totalizados é possível movimentá-los e materializar o ranking.
  8. Estabeleça um breve debate para confirmar o ranking.

Um overview inicial caso os ítens já venham estabelecidos, mas com frequência o ranking é uma etapa sequencial após um processo de ideação, design thinking, onde todos participaram da construção do mural de ideias, desafios ou ítens a serem priorizados.

Um debate final é importante porque por mais provável que a técnica estabelecerá um ranking bastante consistente, é muito comum que algumas alterações de posições sejam acordadas entre os presentes e isso está previsto, a matemática não pode ser absoluta frente à riqueza de argumentos e debate coletivo.

0

Ranking com apenas 7 pontos … por vez

No curso PSPO com o Alexandre Mac Fadden rodou uma técnica de priorização em duplas, ítem a ítem, onde cada discussão entre dois ítens distribuia 7 (sete) pontos de valor. Sendo um número ímpar a ser distribuido entre dois ítens, um deles sempre receberá mais pontos que o outro.

Se fossem 4 ítens a serem priorizados – ideias, projetos, produtos ou serviços – com 4 pessoas participantes, cada um receberia um ítem e a cada 2 minutos trocariam de par, a cada par formado eles debatem e decidem como distribuir 7 pontos de valor entre os dois ítens.

Vamos supor que após 6 minutos com os participantes circulando pela sala e falando com quem ainda não falou, a cada par distribuindo 7 pontos entre eles, … ao final é possível somar quantos pontos cada ítem ganhou e assim gerar um ranking de forma muito descontraída.

Por exemplo, sendo apenas 4 pessoas e 4 ítens pode ter acontecido o relatado abaixo:

  1. O Jorge tem o ítem A e o Mário o ítem B e distribuem 5 para o A e 2 para o B;
  2. O Xavier tem o C e a Renata o D, distribuindo 6 para o C e 1 para o D;
  3. O Jorge agora faz dupla com Renata e decidem 3 pontos para A e 4 para D;
  4. O Mário agora faz dupla com o Xavier, distribuindo 2 para o B e 5 para o C;
  5. A Renata agora faz dupla com o Mário e distribuem 5 para o D e 2 para o B;
  6. O Jorge forma uma dupla com o Xavier, distribuindo 3 para o A e 4 para o C.

Ao final o A tem 11, o B tem 6, o C tem 15 e o D tem 10, ordenando C > A > D > B. A partir deste ranking, construindo um-a-um de forma descentralizada em duplas, é possível debater e ajustar conforme argumentação pontual, mas após várias interações entre várias pessoas o ranking tende a ser bem consistente.

Contorno: É possível se utilizar desta técnica entre vários integrantes e uma lista bem maior de ítens, pressupondo que o ranking seja apenas com o objetivo de ter-se rapidamente uma primeira versão para discussão, não é preciso cruzar todos com todos, o que seria o ideal mas em grande número pode ficar cansativo.

Desafio: É possível númerar todos e a cada dupla os ítens troquem de mãos, evitando que cada um tenha o “seu” ítem, se trocar de mãos a cada rodada este risco é eliminado. Entretanto, é preciso anotar no postit ou folha com quais já cruzou para não repetir a mesma dupla de ítens. É mais caótico, mas divertido e eficiente.

 

0

Balanço de seis anos e meio de TecnoTalks

Resgatei os posts de quase todos os TecnoTalks entre o primeiro em Julho de 2012 e Novembro de 2018, um grupo heterogêneo com mais de 2800 integrantes em 01/12/18. A cada ano o perfil dos eventos e protagonismos mudam, profissionais que chegam ao TecnoPUC e vão embora, hoje vivem em outros estados e países.

O maior desafio era demonstrar ao TecnoPUC que poderíamos seguir regras na utilização autônoma de salas e espaços, com responsabilidade às regras do parque, devolvendo como encontramos, dress code, convivência. As reservas passaram as ser feitas por alguém que atue em uma empresa do parque, mas não mais por uma das empresas.

As regras essenciais não mudaram nestes seis anos e 100 noites de eventos, mudam os temas, mas sempre em terças, quartas ou quintas a noite, raramente em finais de semana, mais raro ainda durante horário comercial. Todos foram gratuitos, houve um de arduino que repassou um custo pelo uso dos kits.

Em resumo as regras consolidadas são: preferencialmente nas noites de terça/quarta/quinta, sem apelo comercial, com seleção via enquete, sem restrições a temas, desde que de interesse, comissões de organização auto-organizadas, sempre no TecnoPUC e cumprindo a risca suas normas, eventos abertos, palestrantes e participantes com ou sem vinculo com as empresas do parque.

Houveram anos em que startup puxou, outros tecnologia, questões mais pedagógicos e mais próximos das faculdades e programas de pós, mas absolutamente todos abertos e sem qualquer apelo comercial, jamais puxado por empresas ou apresentando produtos, o foco sempre é o compartilhamento de conhecimento.

No último ano passei a compartilhar via Face Live, comprei tripé e aos poucos começou a dar certo, o próprio local passou a ser escolhido dependente de disponibilidade de rede cabeada ou wi-fi, a cada evento atingimos mais de 800 visualizações em menos de 48Hrs … assim quem não pode ir assiste remotamente ao vivo e muita gente assiste depois.

Outro babado é que vários eventos passaram a ter participações remotas via Apper.in, Skype ou HangOut, como o Deli Matsuo desde Boston, o Fábio de Salles e o Madalosso desde SP, professores da UFRJ no de Design Thinking na educação … seis anos de adaptação e abordagens variadas … amo muito tudo isso!

https://www.facebook.com/groups/tecnotalks

18/07/12 – Open Space no TecnoPUC – Cartaz – Ata
20/08/12 – Semana LT’s e FishBowls – dia1
21/08/12 – Semana LT’s e FishBowls – dia2
22/08/12 – Semana LT’s e FishBowls – dia3
23/08/12 – Semana LT’s e FishBowls – dia4
24/08/12 – Semana LT’s e FishBowls – dia5
25/09/12 – III TecnoTalks – 1º Dia
27/09/12 – III TecnoTalks – 2º Dia: pré e pós
24/10/12 – IV TecnoTalks – 1º Dia – Introdução RoR
28/11/12 – TecnoTalk 5 – 1ª Noite
28/11/12 – TecnoTalk 5 – 2ª Noite
28/11/12 – TecnoTalk 5 – 3º dia + RHoK
04/12/12 – UStream do Lean StartUp Conference San Francisco
09/12/12 – Ação da Onda Sócio Ambiental em Gravataí
11/12/12 – Tecnotalks 6, diferente de tudo o que já fizemos – pré e pós
20/12/12 – 6 meses de tecnotalks e detalhes 6º TecnoTalks / depoimentos
26/12/12 – McKenna tinha razão
14/01/13 – Reunião comissao especial Tecnotalks 2013
07/03/13 – 1º GUMA-TecnoTalks Dojos (divulgação)
20/04/13 – Idéias em Produção (Falando sério sobre dojos) – 8º TecnoTalks
11/06/13 – 9º TecnoTalks – Dia 11/06, 3ªfeira
18/07/13 – 10° TecnoTalks – Divulgação + Relato completo com fotos
19/07/13 – O melhor Tecnotalks entre tantos inesquecíveis
07/08/13 – Manifesto Luca Bastos – divulgação – relato do evento
20/08/13 – 13° TecnoTalks + GUGC – divulgação – relato do evento
07/09/13 – 14° Tecnotalks vamos planejar gestão do conhecimento
16/09/13 – TTalks FACE e FACIN – divulgação 1 – divulgação 2
22/10/13 – FACE/FACIN – 1ª noite do 15° TecnoTalks
23/10/13 – FACE/FACIN – 2ª noite do 15° TecnoTalks – chamada – relato
09/11/13 – Open Data e Smart City no TecnoTalks – chamada
18/11/13 – Startup Dojo de aniversário da RAIAR – chamada – relato
26/11/13 – Inception do http://www.tecnotalks.com.br/
29/01/14 – 1º Pic-Nic do TecnoTalks no TecnoPUC – chamada – relato
16/04/14 – TTalks sobre Gamification e Gamestorming – chamada – relato
25/04/14 – Vamos falar de lagartas e borboletas
29/04/14 – Startup Dojo com Luis Cipriani do Twitter
03/06/14 – Service Thinking – #1 Evento#2 Conceitos e #3 Visão
16/07/14 – Tecnotalks 2 Anos – DivulgaçãoComemoração e Relato
26/08/14 – ASL e TecnoTalks – Startup Livre Dojo
13/09/14 – Prototipar Hardware – Tecnotalks Arduino de 27/10/14
18/11/14 – Pré-TTalks Agile SubWay Map – TTalks Subway Maps 27/11
21/01/15 – 1º TecnoTalks de 2015 é com o POA Neters (relato pós-evento)
05/02/15 – 11/02 – Happy hour TecnoTalks esquentando os tamburins
26/02/15 – GUMA e TecnoTalks é nitroglicerina
01/04/15 – Relato sobre o POA startup talks na RAIAR
30/07/15 – Tecnotalks Vamos Falar de Empreendedorismo
09/09/15 – Vamos falar de empreendedorismo II
29/09/15 – Global TPUC – Prévia – Programa – Inauguração
07/10/15 – TecnoTalks 06/10 – LEGO Serious Play
08/11/15 – TecnoTalks 24/11 – 12º Troca de Cartões do CRA-RS
23/11/15 – Vamos falar de Empreendedorismo – BMC/LC
25/11/15- CONECTE.ME – Uma nova dinâmica de networking
30/11/15 – 12ª Troca de Cartões ainda gerando valor e reflexões
22/12/15 – Elevator pitch N x N no próximo troca de cartões
11/03/16 – GUAN/TecnoTalks – Papel de HRBP / lição aprendida
12/03/16 – 29 de 03 – TTalks Realidade virtual / Relato
09/08/16 – Mais um TecnoTalks sobre empreendedorismo
17/08/16 – BPW/TTalks – Business Dojo divulga relato extra
24/09/16 – Vamos falar sobre inteligência de negócios
25/09/16 – Semana acadêmica FACIN 2016 divulga info relato
20/10/16 – BI, Big Data, Data Mining e Data Science
02/11/16 – Desenvolvimento mobile – divulga – vídeos/relato
16/12/16 – PHP Laravel – divulgação – relato
17/01/17 – Planejando Carreiras – Felicidade e discriminação
18/01/17 – Planejando Carreiras – Networking e soft skills
19/01/17 – Planejando Carreiras – Planejamento
18/04/17 – TTalks UX dojo – relato
28/07/17 – Documentação / debate e insights
02/08/17 – TTalks Pais & Filhos – divulgação – relato do evento
18/01/18 – Storytelling & Jornada do Herói
21/02/18 – Design Thinking na Educação
28/03/18 – Painel e debate sobre TI Bi-Modal
02/05/18 – Palestras sobre BI e Data Science
10/05/18 – Debate sobre especif. por Exemplos
06/06/18 – Palestras sobre People Analytics
07/06/18 – Debate sobre Linha de Produto de SW
21/06/18 – Palestra sobre arquitetura de software
22/06/18 – Debate sobre Agile e PMBOK
23/06/18 – Toolbox na Educação
23/06/18 – Toolbox no RH
11/10/18 – Debate sobre Domain Driven Design
19/10/18 – Debate sobre GP, SM, PMO e Agile Coachs
25/10/18 – Oficina de BDD e Examplo Mapping
31/10/18 – Debate sobre O papel de PO
08/11/18 – Debate sobre DevOps & Pipeline

 

0

Diferentes alegorias para Débito Técnico

Em meio a um debate sobre Débito Técnico no curso de PSPO no TecnoPUC neste mês de Dez/2018, o Alejandro Olchik da Ionatec compartilhou uma alegoria categórica que merece estar aqui registrada no blog junto a outras que já compartilhei para ilustrar Débito Técnico.

1. Alejandro Olchik e a alegoria do Restaurante

Débito técnico equivale a um restaurante optar por ser mais “ágil” abrindo mão de perder tempo em lavar a louça que suja na cozinha e durante o atendimento, vai chegar uma hora em que não terá mais loça para fazer os pratois ou atender os clientes.

Se não tomar o cuidado de manter a cozinha, louça e instalações limpas, esta decisão oportunista começará a gerar problemas de forma cumulativa e chegará uma hora em que sua operação será paralisada porque de tanto acumular chega-se à inflexão.

2. Ward Cunningan e a alegoria do empréstimo bancário

Ward Cunningham apresentou em 1992 uma metáfora onde o débito técnico de um projeto é como se endividar, decisão que pode acelerar o desenvolvimento e entregas em determinados momentos, mas que deve ser seguido de resgates e quitação.

Sem executar os devidos refatoramentos para reduzir o endividamento, podemos perder o controle e esta dívida não mitigada pode acumular, dívida sobre dívida, colocando em risco todo o projeto.

3. Martin Fowler e seu canvas do Débito Técnico

Eu tenho utilizado uma canvas de mapeamento e planejamento de riscos, quando sob controle é o mesmo canvas – Probabilidade x Impacto. Mas Martin Fowler propõe uma nova perspectiva visual – Domínio (conhecimento prévio) x Risco (prudência).

Fowler propôs um canvas para diagnosticar débito técnico que busca explicitar os fundamentos ou explicações racionais acordadas que o originam, explicitando ser aconteceu(rá) por pressa ou conveniência, um risco calculado ou desconhecido.

4. Neal Ford e a alegoria da Dietzler’s Law

Vale a pena citar Neal Ford da TW, keynote no primeiro dia do Agile Brazil de 2012, ele diz que nós temos 2 usuários, um visível que se beneficia do software que vamos construir e um usuário oculto, que são os próximos profissionais que irão dar continuidade e manutenção futura no software que construímos.

Ele provocou uma reflexão sobre as distrações das abstrações, como a Dietzler’s law sobre o paradoxo de soluções que abstraem e facilitam a construção de uma solução, agilizando resultados iniciais, mas que podem tornar o projeto inviável na reta final, quando exigir especialização ou flexibilidade do framework inicialmente abençoado. Exemplificou alguns que ajudam nos primeiros 80%, dificulta nos 10% seguintes e inviabiliza nos últimos 10%.

5. Uncle Bob e a primazia do Refactoring

Uncle Bob afirma que código de má qualidade NÃO é dívida técnica, a premissa para dívida técnica é uma decisão calculada, uma estratégia não desejável e não sustentável, mas que gera valor antecipado, garantindo uma entrega importante para o cliente, mas sujeito a refactoring.

Este conceito está ligado a boas práticas de engenharia relacionadas à XP (Extreme Programming), a refatoração, ação recomendada como parte importante do processo de desenvolvimento, de forma a ter-se uma visão evolutiva contínua do software.

6. As 8 leis de Lehman (’70)

O conceito de evolução contínua e “refatoração” não é novo, nos anos 70 haviam as 8 leis da evolução de software de Meir Lehman. Com uma abordagem técnica, por 30 anos a Lei de Lehman esteve para o Software do século XX assim como a Lei de Moore esteve para o hardware.

A lei #2 tratava da complexidade crescente e afirmava que se não forem tomadas medidas para reduzir a complexidade do software conforme ele é alterado sua complexidade irá aumentar progressivamente. Deve haver um esforço para reduzir a complexidade final de um sistema enquanto este recebe alterações.

E-Type é um conceito ou categorização proposta por Lehman que caracteriza sistemas que resolvem ou contribuem com um desafio do mundo real, desta forma, sua evolução precisa ser orgânica, conseqüência direta de existir em um mundo real e dinâmico, mutável, evolutivo.

Acordos e estratégias para o Débito Técnico

Débitos técnicos devem ser mapeados e uma estratégia deve ser estabelecida pelo Time Scrum para mitigá-lo permanentemente, eventualmente incorporando-o ao product backlog, sendo reduzido dentro do fator de ajuste ou reserva técnica.

Algumas equipes, após alguns sprints e primeiras entregas, combinam que a cada novo sprint será incluído algo de refactoring, como história ou ocupando um % dedicado a sustentação (reserva técnica).

Alguns desenvolvedores reclamam muito do débito técnico, mas é para ser uma estratégia envolvendo entrega + refactoring, cabe ao time manter explícito em um canvas, mapa ou categorizado no product backlog restante.

Já vi times com uma enorme lista de débito técnico, mas aí a primeira pergunta não é como reduzí-lo, mas porque ele existe, para que serviu plannings, reviews e retrospectivas se esta dívida foi-se acumulando tanto.

Um dos soft skills mais relevantes para um time ágil é a arte da negociação, do poder de argumentação, base para a auto-organização. Afinal, se temos problemas e não sabemos explicá-los, dimensioná-los ou priorizá-los … a culpa não é dos outros.