Mestres, Overdose e Efeito Pendular na Produção de Software

Na onda do ágil, dos mestres (Agile Master, Kanban Master, Scrum Master), como fica a realidade na produção de software?

Compartilhe!

No início tudo era produzir software no prazo, no custo e dentro do escopo…

galaxia-objetivo-desenvolvimento-software

… e hoje continua sendo. Todo produto uma hora tem que ser entregue, tem orçamento limitado, e escopo macro definido.

Desculpe se lhe chateei. ;(

O efeito manada

Na área de produção de software (que “antigamente” chamávamos Engenharia de Software) atualmente estamos tendo overdose de conceitos, frameworks, métodos etc.

Agile, Lean, Kanban, Scrum etc. Muitos “etc”.

Melhoria Contínua (Kaizen do Lean, ou PDCA da administração clássica) é fundamental. Se não há a perfeição, há a oportunidade de buscá-la. E devemos insistir.

Mas como na natureza, a transformação só deve ocorrer após o fim de um ciclo natural, e não no meio dele.

Precisamos pensar sobre a ordem natural das coisas, pois se não há fluidez na ordem natural, fatalmente ocorrerá a desordem natural.

Talvez você pode dizer que “do caos emerge a ordem”. Mas até o caos tem ordem, a matemática pode nos ajudar a provar isso.

Mas não é da Teoria do Caos que estou falando. Estou falando de equilíbrio.

Mestres e Discípulos

mestre japones

Nessa onda de “mudança daquilo que ainda nem mostrou a que veio”, junto com novos modelos de trabalho temos novos papéis dos profissionais envolvidos.

E quantos novos papéis. Oportunidade para mestres temos aos montes.

Acabo de ver um debate no Linkedin sobre “existe Kanban Master?”.

Temos até “Agile Master”.

E tudo começou com o “Scrum Master”.

Numa cultura de aprendizado constante, de mudanças diárias, não sei se dá para termos “Mestres” num contexto onde nada se estabelece, e tudo é um tanto efêmero.

Não dá nem tempo de alguém se masterizar. 🙂

 

/* ser mestre demanda ser absoluto (ou quase) em alguma área de conhecimento. No conceito humano, no mínimo 10.000 horas de prática, segundo alguns autores */

Porque pais e mães de primeira viagem (primeiro filho) sofrem muito na adaptação, mas quando os filhos tem 15 anos, 20 anos, as coisas suavizam?

Porque Warren Buffett fala que devemos investir (investir demanda anos de paciência) e não especular? Que devemos aplicar apenas em nichos que conhecemos (é o Gemba do Lean Thinking)?

Porque os melhores técnicos de futebol dizem que “em time que está ganhando não se mexe”? Porque clubes de futebol que mantém o elenco durante várias temporadas, estatisticamente mantém os melhores resultados?

Porque a masterização demanda tempo, muito tempo.

“Overdose” de melhores práticas tirando o foco

Estamos ficando dopados (e não que isso seja de todo ruim) de Agile, Scrum, Kanban, noestimates, Value Stream, Scrum of Scrum, Business Agility etc.

Ontem ficamos dopados de RUP, CMM/CMMI, (levemente de) de XP, MSF etc.

E muitos mestres e entusiastas estão polarizando as coisas em velocidade descomunal, onde “A é ruim, B é ótimo”, mas no dia seguinte, “B não presta mais”.

O maior barato (sem duplo sentido aqui ok?) é que quando a onda era CMMI, produzíamos software em “fábricas de software”.

Aí começaram a dizer que software não é “linha de produção”, que fábrica de software é algo contrário ao trabalho criativo e artesanal, que é endurecer demais algo que precisa ser flexível.

Então hoje falamos de esteiras de produção de software, de ágil em escala.

E estamos caminhando para, num futuro de médio prazo, termos a predominância do pensamento lean (Lean Thinking) na produção de software.

E de onde vem o Lean (que eu adoro e acredito demais)?

De uma industria, ou fábrica de carros, chamada Toyota.

fabrica toyota lean kanban

Não sei se dá para evitar todas as “drogas” da agilidade, do pensamento enxuto, da horizontalidade que passa perto da anarquia, mas a mente humana reage a tudo isso com uma natural “perda de foco”.

Num mundo VUCA  perder o foco é quase uma certeza para 99% dos profissionais.

Efeito Pendular – ou 8 ou 80

some-ou-suma-radicalismo-producao-software

“Se algo está péssimo, tem que ficar ótimo”. Eis o lema de muitos.

Não temos paciência para sair do péssimo , ir para o ruim, para o regular, para o bom, para o muito bom, e então chegar no ótimo.

A ansiedade é o mal do século, origem de quase todos os desequilíbrios físicos atualmente (leia-se doenças, se quiser entender mais, procure por somatização).

E a ansiedade é força propulsora da ambição de “hoje péssimo, hoje ainda ótimo”.

/* pivotar é diferente de mudar tudo toda hora */

Mas a natureza não dá saltos. Ela é Kaizen (novamente o Lean que tanto admiro), “de poquin a poquin”, com diz o bom mineiro. 🙂

Isso tudo é o efeito pendular que Aristóteles citou ha alguns anos (uns 2300 atrás ~), ou algo tipo teoria dos ciclos econômicos (que se mantém quase em status de lei ha quase 100 anos) no mundo da produção de software.

teoria-dos-ciclos-economicos-mercado-software

Significa que no fim tudo ficará bem, equilibrado. Mas significa também que até que as coisas melhorem, vamos bater na superfície do vale.

/* leia-se ir do 8 ao 80, e depois ficar perto do 36 */

Voltando na “Engenharia de Software”, avaliemos:

  • Ontem muita documentação, hoje “zero documentação”;
  • Ontem executivos davam a direção, agora a direção “emerge do time”;
  • Ontem foco na qualidade, hoje “errar é parte do jogo e ai de quem achar ruim com o time”;
  • Ontem projetos, hoje produtos;
  • Ontem a empresa tinha que dar lucro, hoje “escopo aberto, orçamento ‘dinâmico’ e fim dos prazos”;
  • Ontem Analista de Sistemas, hoje “partial stack developer”.

/* arrisco-me a dizer que poucos são os desenvolvedores “mestres” (lembre-se das 10.000 horas) em Orientação a Objetos, Baixo Acoplamento e Alta Coesão e coisas elementares que são o 80/20 no valor do software executável produzido */

Concluindo

Penso que é necessário sair um pouco da enxurrada de teoria e focarmos naquilo que importa de fato: a entrega de valor e a diminuição do desperdício (leia-se eficácia e eficiência).

Penso que precisamos conhecer o diferente, para saber se ele nos serve.

Mas se ficarmos apenas no “diferente”, ou entendemos em modo “advanced” que a diferença constante é o status quo e harmonizamos (teoria do caos que citei anteriormente, algo para nosso futuro enquanto humanidade) e assim damos cadência aos empreendimentos da vida, ou então vamos viver de hipóteses que por serem muitas vira bagunça e ficam todas implausíveis, onde os resultados desaparecerão.

Viver de hipóteses é como o que fazemos quando procrastinamos: “puxa, legal, é isso! Amanhã eu começo“.

Ou mais na geração Y (da qual que faço parte): “uau, vou arrebentar, já comecei a implementar! Mas amanhã eu continuo“.

E algumas coisas no mundo moderno não vão mudar tão cedo:

  • Lucro é o fim de qualquer empresa, empresas que não dão lucro quebram;
  • Executivos tem um elefante nas costas e respondem por isso;
  • O que não tem um mínimo de prazo ou metas claras não fica pronto nunca;
  • Projetos tem início meio e fim, mas produtos tem seu início e declínio (vide curva S);
  • Testar idéias é necessário. Errar sem critério alegando “cultura do erro” é falta de ética.
  • Pessoas são orientadas a restrições e premissas, sem isso vira bagunça.
  • Menos é mais, simplicidade é um luxo para qualquer empresa ou pessoa.

E para produzir entrega de valor, a depender do contexto, até waterfall pode ser a melhor opção! 🙂

Nem lá nem cá

Eu enquanto Desenvolvedor quero falar sobre entregas sem pressão inquisitória, quero refatorar código para melhorar o sistema, quero fazer provas de conceito sem olhar para o cronômetro toda hora, quero experimentar novas tecnologias e novas arquiteturas sem achar que estou atrasando a meta do sprint e gastando todo o orçamento do projeto.

E também…

… eu enquanto Gerente de Projetos quero falar sobre entregas sem ficar receoso de magoar quando cobro resultado, quero conduzir o time na direção estratégica dada pelo executivo, quero poder dizer não quando o desenvolvedor quer que eu diga sim, quero ajudar a produzir o resultado sendo parte dele, e não mero espectador.

E eu sou as duas coisas (Gerente de Projetos na CLT, Desenvolvedor no MEI), hoje mesmo (sabadão) fritei para entregar uma funcionalidade “muito retrabalhada” onde o meu cliente disse duas vezes “que eu não entendi bem o que ele quis dizer”… só quem viveu isso sabe o que é, hahahaha…

Vamos refatorando o post, afinal, mudar é necessário, mas de “poquin a poquin”…

Engenharia de Software