softwarezen - software zen - home - software zensoftwarezen.me/wp-content/uploads/2016/02/e-book...3...

softwarezen.me

2

SOFTWARE ZENsoftwarezen.me

O que há nesse livro?Carta do autor 3

O valor da gestão 3

Trabalho do conhecimento 4Uma nova era 4O poder da gestão 7A mudança está em nossas mãos 8Um novo mindset 10

Systems Thinking 12O que é um sistema? 14O propósito do sistema 15 O comportamento do sistema 17Fluxo 21Em resumo 25

3


Carta do autor

Esse livro é para você que sofre com um projeto de software desorganizado. É para você que vive cercado por demandas urgentes e que nunca tem tempo para investir em qualidade e inovação. A vida nessa reali-dade é difícil, mas muito comum em projetos de so-ftware por todo o mundo. Além da perda real de pro-dutividade e dos desperdícios gerados, projetos nessa realidade ainda tem que lidar com a falta de motivação das pessoas e com a falta de paciência dos clientes.

Muitas vezes, quem toma as decisões não se envolve com os problemas da equipe. Na vontade de apagar os incêndios de curto prazo, piora a situação no longo prazo. Pessoas entram e saem da equipe o tempo todo e, por causa disso, fica cada vez mais difícil manter os talentos que você precisaria para reverter a situação.

O fato é que todas essas dores e frustrações são cau-sadas por problemas de gestão. Existem maneiras in-teligentes de sair dessa enrascada – ou nem deixar que essa situação se aproxime. É preciso mudar. Mu-dar não só a forma de enxergar o trabalho, mas tam-bém a forma como nos relacionamos com ele.

Para isso eu te convido a explorar comigo nesse livro a problemática e as possíveis soluções para a gestão de projetos de software. Os sintomas podem ser os mesmos, mas o seu problema é único, assim como a solução que precisa ser desenhada para ele. Vamos lá.

O valor da gestão

Alisson ValeDesenvolvedor de software, empreendedor, professor e consultor independente.

4


Trabalho do conhecimentoIntrodução

Uma nova eraO trabalho do conhecimento é uma ativi-dade relativamente nova. Enquanto no de-correr do século XX, o foco foi quase que completo em gerir sistemas de produção de bens em larga escala, no século atual o de-safio é outro.

Foi Peter Drucker que primeiro cunhou o termo “Trabalhador do Conhecimento”. É um tipo de trabalhador que aplica um con-hecimento pré-adquirido para gerar valor; ou aquele que gera valor adquirindo o con-hecimento necessário para tal. Nossas em-presas estão repletas de atividades que de-pendem do conhecimento e da experiência extremamente especializada desses pro-fissionais. O problema é que a cultura de gestão que usamos para lidar com esse trabalho vem sendo a mesma que usamos para gerenciar o serviço manual e repetiti-vo das fábricas, do comércio e dos serviços.

Na era da informação o desafio é lidar com produtos intangíveis, produzidos colabora-tivamente por várias mãos e em ciclos cur-tos de feedback. Tudo dependendo essen-cialmente de pessoas cujo valor do trabalho reside na qualidade das decisões tomadas, e não no volume de trabalho realizado.

Peter Drucker foi pioneiro na identificação e conceituação do trabalhor do conhecimento.

5


As atividades na era da informação são reali-zadas no contexto de sistemas de trabalho operando em zonas de incerteza. Quando tomamos uma decisão não sabemos se ela está certa ou errada até que ela seja valida-da de alguma forma. Podemos concluir assim que todas as nossas decisões são tomadas com base em hipóteses com maior ou menor grau de certeza. E isso muda tudo porque afeta nossa eficácia.

Vamos dar um exemplo. Um programador decide começar a implementar uma nova funcionalidade após terminar uma outra so-licitada anteriormente. Essa decisão foi to-mada em um momento onde ainda haviam algumas hipóteses não-validadas: essa nova funcionalidade é a mais importante que o cliente precisa nesse momento? A funciona-lidade que ele acabou de entregar vai passar nos testes de qualidade? Ela faz o que deve fazer? Ela de fato resolve o problema que o cliente quer resolver?

Repare que validar tais hipóteses pode signi-ficar: checar a priorização novamente com o cliente, fazer os testes de qualidade, validar com o cliente se está tudo funcionando de acordo com o desejado e colocar para fun-cionar em produção para resolver o proble-ma que se pretendia resolver.

A velocidade com que essas hipóteses são validadas antes, ou enquanto, o programador toma a decisão de começar algo novo revela o grau de eficácia do seu projeto.

No trabalho do conhecimento, todas

as nossas decisões são tomadas com base em hipóteses com maior ou menor grau de certeza.

E isso muda tudo porque afeta nossa

eficácia.

6


Esse livro usa a visão sistêmica para destrin-char as causas, efeitos, elementos e forças envolvidas nesses tipos de sistema, mais especificamente em sistemas de trabalho nas áreas de desenvolvimento e manutenção de software.

Durante os meus mais de 20 anos de carreira como líder de equipes, gerente de projetos, empresário, consultor, programador e pro-fessor, deparei-me com contextos onde a complexidade das interações diárias excede a nossa capacidade de análise de causalida-de das coisas. Quando perdemos essa ca-pacidade de ligar os fatos com suas causas, sentimo-nos perdidos. Começamos a lidar somente com as emergências do dia-a-dia, deixando o sistema de trabalho se deteriorar até o caos reinar.

Ao se deparar com essa situação, o gestor normalmente usa sua intuição e começa a procurar pelo “o quê falta”. Faltam funcio-nários? equipamentos? automação? E pro-vavelmente faltem recursos sim. Mas o que você acha que acontece quando ele conse-gue o investimento para obter o que falta e aumenta a capacidade do sistema? A com-plexidade aumenta e os problemas voltam a aparecer com força maior. Ele não modificou o sistema, apenas aumentou seu tamanho. Como muito da complexidade de um siste-ma reside na quantidade e diversidade de interações entre seus elementos, ao aumen-tar a capacidade, no médio prazo, a situação pode piorar.

Visão sistêmica é chave para a gestão moderna

e o caminho para a solução dos problemas que vivenciamos hoje

em nossos projetos – e até na vida pessoal

7


Em 1981, Barry Boehm, um cientista da Universidade do Sul da California, publicou Software Engineering Economics. Nesse livro ele mostrou os resultados do seu estudo que indicava que nada tinha tanta capaci-dade de aumentar os custos de um projeto de software do que uma má gestão. Na ver-dade, estudos posteriores, mostraram que mais de 60% dos nossos problemas estão relacionados com gestão. David Anderson, no livro Lessons in Agile Management cita a conclusão do Barry Boehm e acrescenta: “A lição é que o maior fator de alavancagem para melhorar a efetividade de um projeto de software está em educar gerentes para gerenciarem melhor”.

De lá pra cá o cenário não mudou muito. Tive o prazer de ser apresentado ao Barry Boehm e trocar alguns e-mails sobre dados de um pro-cesso de mudança de gestão que eu estava conduzindo na minha empresa.

Esse trabalho que desenvolvi foi o prime-iro estudo de caso na América Latina sobre um método que ainda estava sendo con-cebido na época, chamado Kanban, e que hoje é massivamente utilizado no mundo. Ele usa os princípios utilizados pela Toyota na implementação dos “sistemas puxados”, que formam o coração do modelo Just in Time japonês. A grande diferença está na adaptação às iniciativas relacionadas ao tra-balho do conhecimento.

O poder da gestão

O cientista Barry Boehm estudou a relação entre os custos de um projeto de software e a má gestão

Esse tipo de entendimento é o que cha-mamos de Visão Sistêmica e é estudado por um campo do conhecimento chama-do de Systems Thinking. Essa é a chave para a gestão moderna e o caminho para a solução dos problemas que vivenciamos hoje nos projetos – e até na vida pessoal.

8


É muito comum ouvir as pessoas em organizações culparem fatores externos pelos problemas que enfrentam no coti-diano. No livro Recreating the Corporation, Russell Ackoff descreve como as forças de um sistema provocam comportamen-tos comuns em organizações: “Nossos problemas são devidos muito mais ao que nós fazemos do que ao que é feito a nós”. Há uma premissa comum que to-dos os nossos problemas são causados por fatores externos. Há de fato proble-mas cuja causa raiz pode apontar para um fator externo, mas isso não significa que não possamos identificar seus efeitos e influenciá-los a nosso favor.

Donella Meadows foi uma das cientistas mais respeitadas no campo do Pensa-mento Sistêmico. Ela nos convida a olhar para um sistema complexo por meio de lentes diferentes em busca de pontos de alavancagem ocultos. Ela diz que: “O sistema, de forma geral, causa o próprio comportamento”. Um evento externo pode desencadear esse comportamento, mas, o mesmo evento externo aplicado a um sistema diferente, provavelmente produzirá um comportamento diferente.

A implicação dessa ideia é muito impor-tante. A causa de muitos problemas não está “lá fora”, mas “aqui dentro”. É muito mais sobre como fazemos as coisas, a for-

A mudança está em nossas mãos

Meadows instiga o pensamento ao sugerir que a causa dos problemas está no ambiente interno

9


ma como olhamos para as coisas ou a forma como pensamos sobre as coisas.

Precisamos de um novo olhar para nossos sistemas de trabalho. Se entendermos que a mudança está em nossas mãos, podemos sair de uma postura reativa. Aquela que “espera” por um evento ou acontecimen-to que fará tudo melhorar. E partir para uma postura proativa e realizadora, onde a mudança é projetada em direção a um pre-sente e um futuro melhores.

Seu projeto de software não é tão diferente de qualquer outro sistema. Para melhorá-lo, você apenas precisa olhar para ele como tal, entender como ele opera, que forças estão agindo e como essas forças interagem entre si e com outros elementos para que o siste-ma tenha o comportamento que tem.

Vamos explorar técnicas e abordagens que visam não apenas procurar por mais enten-dimento dos nossos ambientes de trabalho, mas também procurar oportunidades de mel-horá-lo por meio de alavancas escondidas no meio de toda sua complexidade e incerteza.

A era em que vivemos mostra a força dos sistemas. Depois que você começar a olhar para o seu ambiente com as lentes da visão sistêmica, seu entendimento sobre o mundo a sua volta e sua capacidade de modificá-lo nunca mais serão os mesmos.

Se entendermos que a mudança está em

nossas mãos, podemos sair de uma postura de espera por um

evento que fará tudo melhorar e partir para uma postura proativa

e realizadora

10


No Livro The Lean Mindset: Ask the Right Questions, o casal de autores Mary e Tom Poppendieck explica que um mindset é um modelo mental de como o mundo funciona. Se o nosso modelo mental não se encaixa com o quê fazemos no dia a dia, temos dor e frustração. Se, por outro lado, as duas coisas se encaixam temos energia e motivação. Isso nos diz que desenvolver o seu mindset é tão importante quanto aprender métodos, práticas e ferramentas.

“Desenvolver um mindset não tem a ver com copiar práticas, mas com desenvolver a capacidade de fazer as perguntas certas, resolver os problemas certos e fazer a coisa certa na situação que você tem nas mãos”, explica Mary Poppendieck.

As idéias neste livro estão apoiadas em um mindset que pode parecer contraintuitivo para muita gente. Mas para você eu tenho certeza que não vai ser assim. E a razão é muito simples. Você vivencia os problemas no dia a dia e sabe que tem algo errado. O mundo da gestão nas empresas usa o mind-set da economia de escala para organizar seus processos. E o que você vai encontrar aqui é o mindset da economia de fluxo.

Na economia de fluxo, onde o trabalho do conhecimento opera melhor, eficácia e tem-po são mais importantes do que eficiência

Um novo mindset

Mary e Tom Poppendieck explicam a importância de encaixar o mindset com as tarefas do cotidiano

11


e volume. Isso significa que ser eficaz, re-solver o problema certo no tempo certo, é mais importante do que produzir muita co-isa com muita velocidade. Se você pensar bem, os modelos de gestão mais utilizados hoje foram criados para otimizar o trabalho de produção em massa que fez a economia girar no século passado. Quanto mais você produz, mais você vende. Fazer mais e mais rápido é a norma.

Mas o mundo mudou, a economia se tor-nou criativa, os problemas complexos e os nossos modelos de gestão que formaram a nossa cultura não acompanharam o pro-cesso. E por isso precisamos ajustar nossa mentalidade. A boa notícia é que há um ca-minho. A virada do século XX para o XXI foi acompanhada de um esforço para entender o mundo. Novos métodos e uma nova filo-sofia surgiram para alinhar a satisfação de todas as pessoas envolvidas na busca pelos resultados desejados.

Para o trabalhador do conhecimento,

ser eficaz, resolver o problema certo no

tempo certo, é mais importante do que

produzir muita coisa com muita velocidade

12


Systems ThinkingCapítulo 1

Para mergulharmos nessa jornada rumo a um novo mindset a primeira coisa que você precisa entender é que o seu projeto, a sua empresa e o seu departamento são todos “SISTEMAS”. Os sistemas estão em todas as partes. O seu carro é um sistema. Seu corpo é um sistema. Ele tem uma função ou propósito e interações entre esses elemen-tos. O que faz um sistema atingir o seu pro-pósito são as interações entre os elementos que o compõem.

Você pode entender como um sistema fun-ciona dividindo-o em partes e estudando cada uma das partes separadamente. Mas o ponto é: você não consegue entender porque um sistema funciona do jeito que funciona analisando suas partes apenas.

Por exemplo, você não consegue explicar porque as pessoas dirigem do lado direito do carro, ou porque um carro tem cinco lu-gares desmontando suas peças e estudan-do-as individualmente. Todas as explicações do porquê um sistema se comporta do jeito que se comporta estão FORA do sistema. É por isso que você precisa de visão sistêmica. Para mudar o comportamento de um siste-

Projetos de software são sistemas, assim como uma empresa, o corpo humano ou motor de um carro

13


ma você precisa primeiro entender o porquê, a razão, a causa-raiz daquele comportamento.

Um problema muito comum que a falta da visão sistêmica é culpar as pessoas pelo pro-blemas. As pessoas cometem erros, é verda-de, mas o que faz o sistema de trabalho se comportar de determinada maneira é muito mais a forma como as interações estão or-ganizadas, do que os elementos do sistema em si. Não pense que trocando uma pessoa por outra vai solucionar o problema, a não ser que essa nova pessoa mude o sistema.

Visão sistêmica é o primeiro passo para a verdadeira gestão. É parar de culpar as pes-soas pelos problemas e começar a projetar como o sistema de trabalho, de fato, deve ser organizado.

Um problema comum da falta da visão

sistêmica é culpar as pessoas pelos

problemas. O que faz o sistema de trabalho se comportar

de determinada maneira é a forma como as interações estão organizadas

14


O propósito ou função de um sistema é sempre definido de acordo com o impacto no sistema de mais alto nível na qual ele faz parte. Se um sistema faz parte de outro de mais alto nível, o chamamos de ”subsiste-ma”. Assim, o motor é um subsistema que tem a função de fazer a roda girar no siste-ma de tração do carro. E esse por sua vez, tem a função de fazer o ”sistema carro” se locomover. Esse, finalmente, tem a função de fazer o “sistema de transporte urbano” te levar de um lugar para outro.

O seu time também tem um propósito. Pode ser, por exemplo, automatizar o pro-cesso de compras da empresa por meio da criação de um software.

Se você tirar o motor de dentro do carro ele não cumpre sua função. Se você tirar o carro de dentro da cidade e colocá-lo em um navio em alto mar ele também não cumprirá sua função. Assim, um subsiste-ma só cumpre sua função se estiver inse-rido e apoiado pelo seu sistema de nível superior. Um subsistema e um sistema de mais alto nível não estão associados por uma relação de hierarquia, mas por uma relação de propósito ou função.

Quando em relação a um sistema de nível superior, um subsistema não faz coisas. Quem faz é o sistema superior. Não é sua mão que escreve, é você. Não é seu cére-

O que é um sistema?

A conexão entre sistemas não é feita

por uma relação de hierarquia, mas por uma relação de

propósito ou função.

15


O propósito do sistemaVocê pode projetar um sistema para que ele atinja um determinado propósito. Mas você não pode definir o propósito de um si-stema pré-existente e esperar que ele per-siga o propósito por conta dessa atribuição pura e simples. O propósito de um sistema é sempre observado e tirado de seu com-portamento, nunca definido por decreto.

As declarações de missão de empresas são bons exemplos para ilustrar esse ponto. Tais declarações não servem como base para o entendimento do propósito daquela empre-sa. Um empresa pode ter uma missão pom-posa de “mudar o mundo fazendo o que faze-mos”, mas se ela opera seus projetos apenas visando reduzir seus custos e aumentar sua receita, o propósito observado dessa empre-sa na verdade é gerar lucro. O propósito de um sistema está ligado ao resultado gerado e não ao resultado pretendido.

bro que pensa, é você. Não é o motor que gera movimento, é o carro. O seu produto não é criado por um programador, mas pelo seu time ou pela sua empresa. Os subsiste-mas só cumprirão sua função se estiverem conectados a um sistema superior que os alimentem com os inputs requeridos e que aproveitem os outputs gerados.

Um subsistema não faz coisas. Quem faz é o sistema superior. Não é sua mão que

escreve, é você. Não é seu cérebro que pensa, é você. Não é o motor que gera movimento, é o carro. Os subsistemas

só cumprirão sua função se estiverem

conectados a um sistema superior

16


Uma vez, ao chegar a um novo trabalho de consultoria, perguntei ao Diretor de TI da empresa qual era o propósito do time de desenvolvimento. A resposta veio rapida-mente: “Desenvolver, em software, novas soluções de negócio para a empresa”.

Após 30 dias de análise e visualização do sistema de trabalho do time, verifiquei de forma detalhada o trabalho que aquele time processava. Cheguei a conclusão que 65% das demandas eram para ajustar fun-cionalidades que já estavam em operação no negócio, 34% eram para solucionar problemas gerados pelo próprio software ou pela sua má-utilização, e apenas 1% eram para desenvolver novas soluções de negócio para a empresa.

Ao me reunir novamente com o diretor e mostrar os dados ficou fácil concluir qual era o propósito real observado: “sustentar a plataforma de software que apóia o negó-cio da empresa”.

O propósito de um sistema em que atuamos não é o que queremos, mas o que fazemos. Para mudar o seu propósito é preciso mu-dar o que fazemos. E para isso é preciso entender qual é o propósito escondido no resultado que o sistema gera hoje.

O propósito dos sistemas tem a ver com o resultado do que as pessoas fazem, e não com o que é esperado ou instituído.

17


Embora o entendimento do propósito de um sistema seja absolutamente essencial. O ponto de maior interesse é o compor-tamento do sistema. Afinal, o propósito é gerado pelo comportamento. E o que qu-eremos é o atendimento a um propósito desejado, não um resultado colateral que nos desvie disso.

O comportamento de um sistema é for-mado pelas interações entre seus elemen-tos. A decorrência disso é que não são os elementos em si que causam o comporta-mento que você não deseja no seu sistema, mas a interação entre eles. Vou explicar isso melhor com um exemplo.

O gerente de desenvolvimento de uma cer-ta empresa de software está em um clien-te ajudando a equipe comercial em uma venda. Para facilitar a venda, o gerente se compromete a fazer um ajuste no software, permitindo que este possa agora incorpo-rar a política de cobrança que o cliente usa para receber pagamentos. Para expedir ra-pidamente a demanda e conquistar o novo cliente, o gerente de desenvolvimento liga para um dos seus desenvolvedores e solici-ta o ajuste que, aparentemente, é simples e levaria apenas algumas poucas horas de trabalho.

O comportamento do sistema

A interação dos elementos do sistema forma o com-portamento dele, cujo resultado leva ao propósito

18


O programador faz o ajuste e incorpora a alteração no repositório de código do pro-duto. Ao mesmo tempo, um certo número de outros ajustes solicitados por outros clientes são também realizados e incor-porados a mesma baseline de código-fon-te. Uma release é gerada e divulgada para os mais de 150 clientes da empresa. A alteração na política de cobrança feita pelo desenvolvedor causa um resultado impre-visto na cobrança de vários outros clientes. O suporte técnico da empresa é inundado com pedidos de socorro dos clientes que temem por perdas financeiras iminentes. O problema escala para o próximo nível. A notícia chega aos diretores das empre-sas clientes. Eles ligam para a diretoria da empresa de software que até o momento não sabia de nada. Esta chama o gerente de desenvolvimento para esclarecer o que está acontecendo. A resposta dada pelo gerente é simples mas revela o desconheci-mento dos principais pontos tratados nesse capítulo:

- O problema foi criado por um dos desenvo-lvedores. Ele fez uma alteração no sistema que afetou o modelo de cobrança de vários outros clientes. Já corrigimos o problema, mas ainda estamos tentando resolver todas as inconsistências que esse bug gerou nas bases de dados do cliente. Um patch de correção deve ser liberado em breve.

Quem é o culpado do problema na sua visão? O programador que fez o ajuste so-

Sistema mal estruturados buscam culpados e reduzem dramaticamente a satisfação das pessoas com o tra-balho que realizam.

19


licitado? O gerente que se deixou ser pres-sionado pela demanda de um novo cliente? a equipe comercial que o pressionou para a concretização da venda? Ou a omissão dos diretores que não estão acompanhando de perto o que acontece na empresa?

O primeiro ponto a se destacar nessa histó-ria é a necessidade que temos de apontar um culpado para esclarecer causa e efeito. A falta de visão sistêmica nos sujeita à ar-madilha de desconsiderar as interações e focar apenas nos elementos. Alguém fez alguma coisa errada. precisamos apenas descobrir quem foi para punir, demitir ou chamar sua atenção e, assim, evitar novos erros no futuro. Não é assim.

Como você já deve ter percebido, não foi o programador que gerou o problema, nem o gerente, nem o comercial, nem o diretor. Foi o sistema.

Pense bem. Não é o elemento do sistema que produz o comportamento, é o sistema. Assim, culpar as pessoas pelos problemas que ocorrem é sintoma de falta de visão sistêmica. A ausência dessa visão impede o enquadramento correto dos problemas e a exploração de oportunidades de melhoria.

“Todos nós produzimos o resultado que não queremos no sistema. E nós o fazemos fora da resposta racional às restrições, incenti-vos e punições a qual o sistema nos sujeita. O comportamento do sistema sai do próprio

Culpar as pessoas pelos problemas que ocorrem

é sintoma de falta de visão sistêmica. A

ausência dela impede o enquadramento correto

dos problemas.

20


sistema. Está nas relações, no propósito. Não nos elementos, nas pessoas, nos atores dentro dele. Assim, o fato das pessoas agirem de modo a produzir resultados que ninguém quer, não é culpa das pessoas. É culpa do comportamento irracional das pessoas no sistema. A pergunta é: ’o que há de errado com o sistema’, e não ‚o que há de errado com as pessoas que estão nele.” Donella Meadows

As pessoas são elementos do seu sistema, assim como seus clientes, seu produto, e por aí vai. O esforço de gestão deve se concen-trar nas interações do sistema, não nos seus elementos.

Trocar uma pessoa que comete um erro por outra nunca resolveu seus problemas porque a falha não ocorreu por causa de uma única pessoa, mas por causa do funcionamento do sistema como um todo. A não ser que uma nova pessoa consiga intervir no sistema, em suas interações, trocar A por B apenas vai te dar esperança de solução. E precisamos mais do que isso para resolver problemas comple-xos como os que temos.

As pessoas são elementos do sistema. O esforço do gestor de software tem que ser direcionado para o design das interações entre os elementos.

21


FluxoToda vez que você tem elementos acumu-lados no seu sistema, você tem estoques. Além das pessoas que trabalham no seu time ou que interagem com ele, são elementos do seus sistema: o software em si, as linhas de código-fonte, cada nova versão que você gera, um bug registrado na sua ferramen-ta de registro de tickets, uma demanda de ajuste, um novo projeto e essa lista avança praticamente sem fim. Não é importante conhecer ou rastrear todos esses elemen-tos, o importante é saber que quando eles se acumulam de alguma forma no sistema eles formam o que chamamos de “Estoques”.

Quando você olha para um sistema, o que você vê de imediato são os estoques. Eles são mais fáceis de serem vistos por causa de sua natureza estática. Assim, o conjunto de bugs não corrigidos é um estoque, assim como o conjunto de funcionalidades em desenvolvimento e a lista de projetos apro-vados que aguardam para serem iniciados.

Os estoques são normalmente itens con-táveis e mensuráveis acumulados no si-stema em um certo ponto. Mas podem ser também coisas que você vê ou sente. Não precisam necessariamente serem coisas físicas. Podem ser ideias, oportunidades, problemas e até a satisfação dos seus clien-tes. Esse último é um bom exemplo de um estoque intangível. Como todo estoque, o nível de satisfação dos clientes pode subir

A observação do fluxo dos elementos do sistema é essencial em projetos de software

Quando você olha para um sistema o que você vê de imediato são os estoques. Se você olha

novamente e os estoques mudaram, o que você é

”fluxo”

22


ou descer de acordo com os eventos que acontecem no seu dia a dia.

Ao longo do tempo, os eventos que aconte-cem no sistema causam alterações nesses estoques. Por exemplo, um programador fi-naliza o desenvolvimento de uma nova fun-cionalidade, integrando o que foi feito com o repositório de código do produto e ge-rando uma nova versão. Esse evento causa uma diminuição no estoque de funcionali-dades em desenvolvimento e um aumento no estoque de funcionalidades que preci-sam ser testadas.

A essa variação nos níveis dos estoques do sistema nós damos o nome de “Fluxo”. É basicamente a percepção do estado de um sistema evoluindo ao longo do tempo por conta da variação em seus estoques.

Em desenvolvimento de software, o pro-cesso de fluxo se revela como sendo a transformação de um futuro projetado em um passado conhecido. A transformação de hipóteses em fatos em um terreno de incertezas que vai se solidificando na medida em que software é colocado nas mãos de nossos clientes para resolver seus problemas. Por conta disso, é de suma importância manter esses estoques sem-pre em um nível muito baixo. Os estoques guardam consigo muitas hipóteses.

Por exemplo, no estoque de funcionalida-des desenvolvidas temos dúvidas ainda

Fluxo é a percepção do estado de um

sistema evoluindo ao longo do tempo por

conta da variação de seus estoques

23


não respondidas como: o programador fez o que precisava ser feito? Há bugs ainda a serem corrigidos? A usabilidade está boa? Já no estoque de funcionalidades testadas, mas que ainda não estão em produção há outras dúvidas: é isso mesmo que o clien-te quer? Alguma coisa relevante ainda não foi testada? O usuário final vai se adaptar com a usabilidade? Teremos problema para instalar o que foi feito nos servidores? Vai funcionar bem no ambiente de produção?

Assim, cada estoque carrega consigo um conjunto de hipóteses que só serão valida-das em algum momento do futuro. A chave está em diminuir esse tempo de validação e, para fazer isso, temos que trabalhar com estoques pequenos. Essa é uma das filoso-fias das vertentes de métodos Lean para desenvolvimento de software, como o Kanban, proposto por David Anderson, que batizou a abordagem com o mesmo nome do método utilizado por Taiichi Ohno para a implementação do sistema puxado no mo-delo Just In Time da Toyota.

Quando as mudanças de nível em um cer-to estoque interferem no fluxo de entrada ou saída do mesmo estoque, nós temos o que chamamos de “feedback loop”. Muitos exemplos desse processo aparecem nos mo-delos de gestão dos métodos Ágeis para de-senvolvimento de software, como o Scrum.

Nos métodos Ágeis, o escopo de um pro-jeto de desenvolvimento é, preferencial-

O segredo é trabalhar sempre com estoques pequenos no seu sistema. A mesma filosofia utilizada na abor-dagem de gestão Lean e implementada na prática em projetos Ágeis de software.

24


mente, aberto a mudanças. O time, junto com o cliente, planeja apenas o trabalho de um curto período de tempo (normalmente 2 semanas). Ao final desse período, essas funcionalidades são efetivamente entre-gues para uso. O contato do cliente com a solução, mesmo que ainda parcial, gera aprendizado sobre os rumos do projeto e isso afeta o estoque de funcionalidades não iniciadas (o backlog) - algumas podem ser descartadas, outras adicionadas. Em análise sistêmica, isso é o que chamamos de feed-back loop.

Todos os sistemas operam por meio des-ses feedback loops e é muito importante saber identificá-los para conseguir “ver” a dinâmica de um sistema. Feedback loops podem ser desenhados para controlar os estoques. Eles podem aumentá-los ou dimi-nui-los ao longo do tempo. O importante é entender que os ciclos de feedback permi-tem que os sistemas operem por si só, ou seja, que haja fluxo contínuo ao longo do tempo.

Os ciclos de feedback são armas de alavan-cagem sistêmica importantes. Saber que es-toques uma determinada ação realimenta, afeta dramaticamente sua capacidade de entender ou intervir na dinâmica de fluxo dos sistemas de trabalho. Pode ser aplicado para o fluxo de tarefas, de entregáveis, de releases ou até o fluxo de colaboração entre as pessoas.

O Pensamento Sistêmico é o ponto de

partida para a mudança de mindset que você

precisa para reinventar a forma como você faz

gestão de projetos

25


Em resumoO Pensamento Sistêmico, mais conheci-do como Systems Thinking, é o ponto de partida para a mudança de mindset que você precisa para reinventar a forma como você faz gestão nos seus projetos. Essa mudança passa por aceitar as limitações da gestão tradicional, aquela que atua sobre os elementos do seu sistema, e abraçar a importância da relação entre as partes, e entre elas e o todo.

Essa nova mentalidade foca em entender a estrutura do sistema e a dinâmica dos acontecimentos. Ela olha para as interações entre os elementos e procura ali a alavanca-gem necessária para melhorar o processo e as relações sociais no trabalho.

Espero que, ao final desse capítulo, o leitor comece a enxergar tudo a sua volta como um grande conjunto de sistemas e subsi-stemas interligados entre si. Com funções ou propósitos claros e com seu comporta-mento gerado pelas interações entre seus elementos.

System Thinking é o primeiro passo para repensar a forma de gestão de projetos de software

26


EM BREVE

Capítulo 2: Estratégias para Intervenção Sistêmica em

Projetos de Software

softwarezen - software zen - home - software zensoftwarezen.me/wp-content/uploads/2016/02/e-book...3...

Documents