PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Gerenciamento de Mudanças

  • O Mapa de Transformações

    O Mapa de Transformações

    “Mude antes que seja forçado” é um dos mantras mais famosos de Jack Welch. O que está vivo muda – tenta se adaptar – na marra, na sorte ou por querer. Se para melhor ou pior, o tempo dirá; No caso dos negócios, os clientes julgarão.

    A mudança é uma certeza muita incômoda em tempos de tantas incertezas. Existem estratégias e ferramentas mil para a redução dos desconfortos e riscos. Este artigo apresenta uma, o Mapa de Transformações.Com certeza você já viu negócios que se fingem de mortos. Seus sinais vitais – balanços e balancetes – estão normais. Há um vermelhinho ali e outro acolá, mas não é nada que um bom plano de contenção de despesas não corrija. O predador (Amazon, Netflix, Uber, AirBnb, Marfrig, <coloque seu favorito aqui>) circula, cada vez mais próximo. Mas é preferível acreditar no mágico escudo invisível das barreiras de entrada (legislação, cultura) e permanecer quietinho – quase morto.

    Um pouco mais raros, mas não menos folclóricos, são os empreendimentos do tipo “metralhadora giratória sem controle”. Porque esse papo de “controle”, dizem, é coisa vintage. TUDO vira hipótese factível; TODOS merecem ser ouvidos; TODAS as balas devem ser disparadas. Geralmente, um único recurso é escasso: a paciência. E dá-lhe barulhentas saraivadas de experimentos seguidos de meia-volta-volver (pivotagens). No final das contas, na imensa maioria das vezes, registram-se um incalculável aprendizado e prejuízos muito bem mensurados. E só.

    Entre esses extremos circula a grande maioria de nossas firmas. Assustadas, mas cientes ou temerosas daquela bipolaridade.

    E Por Falar em Bipolar

    Nosso mundo, em quase todas as searas e assuntos, anda perigosamente viciado em dilemas. É a vitória do OU em detrimento do E. É a onipresença do cobertor curto, a bandeira dos novos tempos.

    Ao que tudo indica, foi-se a era d’O Dilema da Inovação (Clayton Christensen – M. Books, 2011). Porque o presente – o mercado e clientes atuais – não é mais uma zona de conforto onde podemos pendurar nossas redes. Aliás, será que em algum momento na história das organizações essa zona realmente existiu? Muito antes de Christensen, muita gente falou e escreveu¹ sobre a necessidade de escutar o amanhã – particularmente aquele que vinha soprado por novas tecnologias – sem descuidar do aqui e agora.

    Essa conversa se renova e foge da retórica rasa em Dual Transformation, de Scott D. Anthony, Clark G. Gilbert e Mark W. Johnson (HBR, 2017). Resumindo: ? = A + B + C

    Duas Transformações e um Bebê

    O diagrama ao lado, o Mapa de Transformações, guiará esta breve apresentação. Ele foi surrupiado do livro citado acima, onde é apresentado como “Opções estratégicas para líderes”.

    O eixo vertical representa o QUE a  empresa faz. São os Trabalhos a Executar (ou JTBD – Jobs to be Done, como apresentados no artigo anterior). No eixo horizontal temos COMO a empresa realiza aqueles trabalhos. O COMO são os produtos e serviços, o know-how aplicado e os componentes financeiros (modelos de precificação e cobrança, por exemplo). O quarto de círculo menor representa o núcleo do negócio, o core business atual. As três grandes setas nos ajudam a pensar as transformações viáveis.

    Você espera um exemplo e eu vou te apresentar o Agostinho Carrara, famigerado motorista de táxi. Sua empresa é de um homem e um JTBD só: levar alguém de algum lugar para outro. Agostinho anda p da vida com a concorrência do Uber e afins. E mais p da vida com ele mesmo, por ter ignorado o conselho do Jack. Agora, precisa mudar na marra.

    Agostinho cogita o primeiro caminho (Adjacências) porque adora atalhos. Em outras palavras: ele considera agregar outro JTBD sem mudar nadinha seu modus operandi. “Além de transportar alguém, por que não levar coisas de um lado para outro?” Passado o entusiasmo de dois segundos, repara que entraria em concorrência com seu ex-inimigo favorito, o motoboy. E desiste da ideia, resmungando: “O mar não tá azul e nem pra peixe nas adjacências”.

    Mudar COMO o trabalho é executado é o que fazemos com a Transformação A. Significa reinventar o hoje. E Agostinho viaja nas possibilidades: melhorar o condicionador de ar; nada de funk no rádio, só os 3 B’s da música clássica (Bach, Beethoven e Bezerra da Silva); balinhas sortidas e água gelada; uma cervejinha, talvez (dá pra colocar um frigobar no porta malas?); serviço de agendamento via app ou 0800 (neste caso, a menina tem que ter a voz da Camila Pitanga!). Agostinho viaja e faz contas – com uma única certeza: “como tá não pode ficar”.

    Dezesseis segundos de ânimo renovado e nova ducha d’água fria: com exceção da Camila Pitanga, todo o resto pode ser copiado facilmente pela concorrência. “Preciso mudar o hoje, mas isso não garante o amanhã”.

    Criar o amanhã é a motivação da Transformação B. Além de agregar novas responsabilidades (novos JTBD), Agostinho também precisa mudar o COMO (trabalha, precifica, cobra etc). Ele admira o case da Amazon: “caraca, os caras foram do varejo para serviços na nuvem! E hoje abocanham 30% desse mercado!!”

    “Trocar essa carroça por um SUV bem chique e oferecer passeios por pontos turísticos sem a chatice dos guias tagarelas; Montar um roteiro exclusivo para paparazzis iniciantes e fãs enxeridos- casas, bares e praias dos famosos; o bilhete único do agostinho: táxi, parapente, prancha de surf e 500ml de água de coco”…

    Enquanto o Agostinho sonha, é preciso fechar a equação proposta acima: ? = A + B + C.

    C é de Capacidades. Quais ativos existem hoje e precisam ser aproveitados e replicados em todas as transformações. Não se trata de qualquer ativo, mas aqueles difíceis de copiar. O Agostinho conhece bem os seus: simpatia, criatividade e domínio ímpar dos roteiros exóticos da cidade. Numa empresa menos modesta, ATIVO deve ser interpretado da forma mais ampla possível: posses, patentes, informações, conhecimento, processos e por aí vai.

    Léxico

    Há pistas indicando que “Gestão de Mudanças” está caindo em desuso. O termo “Transição” já aparece aqui e acolá. Não é apenas uma troca de palavras. A Gestão de Transições é mais ampla, entende a Complexidade e abraça o Pensamento Sistêmico². Falaremos em Gestão de Transformações? Não creio. Mas é bom ficar de olho.

    Na seara Enxuta (Lean), o glossário original nos dá três tipos de mudanças: Kaizen (melhoria contínua), Kaikaku (mudança radical) e Kakushin (mudança total). A primeira é condição inegociável de qualquer ser ou sistema que se pretenda viável. As demais, com alguma boa vontade, podem ser relacionadas com as Transformações A (Kaikaku) e B (Kakushin).

    O Mapa de Transformações é uma ferramenta para pensar, uma ferramenta conceitual³. Ele nos ajuda a apreciar nosso portfólio de produtos e serviços de uma maneira diferente – nos ajuda a avaliar melhorias e oportunidades. Ele parte da ferramenta JTBD e a enriquece. Este mapa é uma das 22 ferramentas apresentadas na oficina Design de Negócios Viáveis. (Pegue aqui sua versão em PDF).

    Por fim, 1100+ palavras passadas, me diga uma coisa: você sentiu falta dos termos inovação e disrupção? Sério?

    Notas

    1. E dois caras, diferentes em quase tudo, merecem destaque: Peter Drucker e Stafford Beer. O mundo merecia um debate entre os dois, que tinham “inimigos” comuns: a ignorância e o Milton Friedman.
    2. Não se trata de uma contradição – não estou propondo outro duelo: Gestão de Mudanças X Gestão de Transições. São coisas distintas e, no meu modo de entender, complementares.  
    3. Por favor, me ajude a definir qual é o melhor nome para esse tipo de ferramenta: Para Pensar ou Conceitual? Qual funciona melhor?
    4. Crossroads é o nome da foto no topo, de autoria de Eric Fischer. A imagem do Agostinho foi surrupiada do Sensasionalista.

  • D.E.V.A.G.A.R.

    Como apresentei no post anterior, DEVAGAR é um acrônimo para um conjunto de princípios que deveriam nortear um processo de desenvolvimento ‘business-centric’. Confesso, não deixa de ser uma provocação. E um contra-ponto ao ABCDEF que, segundo seus autores, seria ‘business-centric’. Na minha opinião, mais que ‘business-centric’, aquele conjunto de princípios – que, aliás, é muito legal – é mais ‘agile-manifesto-centric’ ou, em outras palavras, ‘developer-centric’.

    Mas, mais do que criar polêmica (essa cansa), eu queria descrever com mais detalhes os 7 princípios que compõem o DEVAGAR:

    D)emonstrar Valor de maneira Iterativa
    Deveria ser, Iterativa & Incremental. Parece frescura, mas faz diferença. Iterare, no latim, significa repetir. Aqui indicamos que repetimos diversos passos (no processo de desenvolvimento), mas a cada repetição nós agregamos real valor. Numa leitura “ágil”, é o mesmo que dizer “entregamos software rodando” em cada ciclo (ou iteração). Não curto o radicalismo: nas primeiras iterações, ou exclusivamente na 1ª iteração, software rodando pode ser menos importante que uma boa compreensão do negócio. Da mesma forma que ele pode ser muito importante para a equalização de visão entre todos os stakeholders. Mais do que um processo, o que determina o Real Valor a ser entregue em uma iteração é o projeto. E cada projeto é único. Mensagem mais importante (para o negócio e seus usuários): se uma iteração se encerra e você não consegue perceber o Valor, algo errado aconteceu. E é verdade: software rodando tem muito mais valor que uma série de modelos UML ou afins.

    E)ntender (e Melhorar) o Negócio
    É difícil aceitar que um projeto seja tocado sem que boa parte da equipe tenha uma mínima compreensão sobre o negócio que está sendo automatizado. É difícil entender a razão para tal alienação ser tão comum em nossa área. Mas o princípio aqui vai além: além de uma boa compreensão do negócio e dos projetos afetados pelo projeto, um processo ‘business-centric’ incentiva a busca por melhorias.

    V)alorizar os Ativos de Software
    Está aqui um princípio que, salvo engano, não vi formalizado em nenhuma proposta de processo. Ele deveria ter dois efeitos:

    1. Garantir a qualidade do software que está sendo produzido. Se bem empacotada (documentada e difundida), a aplicação ganha sobrevida. Vale apelar para um velho chavão: ativos de software, ao contrário dos ativos físicos, ganham mais valor quanto mais são utilizados. Todo software (de negócio) deveria ser construído para durar… muito.
    2. Dar sobrevida aos ativos existentes (também conhecidos como sistemas legados). Trata-se de um dos principais alvos das iniciativas SOA. Mas, hoje em dia, serão raros os projetos que não estabeleçam um mínimo relacionamento com software existente. Combater a síndrome NIH (Not Invented Here) e dar valor para aplicações (conhecimentos!) existentes é uma boa prática.

    A)daptar o Processo
    Taí um princípio que, se adotado pela (IBM) Rational desde o início (do RUP), teria evitado uma série de problemas. Se todo projeto é único, como acreditar em um único processo? Toda organização possui e vive seus valores e costumes. Algumas sobrevivem a eles (hehe.. brincadeirinha). Essa base, mais um conjunto de princípios (ou boas práticas, como as descritas aqui), dá forma à um meta-processo. Um framework que seria posteriormente adaptado para cada tipo de projeto e também para cada projeto.

    No nível mais baixo (um projeto), quatro variáveis principais afetam a configuração de um processo: O Negócio (sua estratégia, processos, departamentos e pessoas afetados); o Tipo de Aplicação (Transacional, Analítica ou Utilitária); a Tecnologia e o perfil da Equipe. Claro, várias outras questões (regulatórias, SOX, Bacen, Basiléia… por exemplo) também podem gerar considerável impacto no desenho dos processos de desenvolvimento e gerenciamento do projeto.

    G)erenciar Requisitos (e Mudanças)
    Vira e mexe, há tempos, o dado pipoca por aí: requisitos (e mudanças) estão de alguma forma relacionados com 80% dos problemas dos projetos que fracassam. Como eles (os projetos fracassados) não são poucos, é inaceitável que este princípio não conste de um processo para desenvolvimento de software. Pode parecer chatice (de certa forma o é), mas “balancear prioridades dos stakeholders” não é o termo adequado. Parece até “forçada de barra” para arrumar uma letra B (e assim compor o perfeito ABCDEF). E por falar nisso, gerenciar requisitos não significa lotar paredes com post-its coloridos.

    A)tacar os Riscos
    Assim como os requisitos, o mau gerenciamento de riscos também está entre as principais causas das falhas em projetos de software. Como Grady Booch já falava em 96 , “se você não atacar os riscos, eles o atacarão”. O verbo é este mesmo: Atacar (a redação de um princípio deve ser clara e direta). E é equivacada a impressão de que riscos são questões exclusivas de arquitetura. Um bom entendimento do negócio (princípio #2 acima), significa também a descoberta de riscos e até uma possível antecipação de mudanças. Aliás, os riscos de negócio são mais perigosos que os riscos de arquitetura (por mais que algumas péssimas aplicações tentem nos provar o contrário).

    R)espeitar os Usuários
    É chato que algo assim tenha que aparecer numa lista de princípios. Mas, infelizmente, se fez necessário. É bom que seja o item de fechamento da lista. Força a revisão de muitos fatores que podem ter ficado implícitos. Por exemplo: vamos ouvir e gerenciar todas as expectativas dos usuários. Mas não fugiremos da responsabilidade de sugerir melhorias, ou de alertá-los sobre riscos em potencial. Respeitaremos a inteligência e o tempo dos usuários estudando seu negócio, falando sua língua. E, mais importante, nos comprometendo com seus objetivos de negócio.

    Por tudo isso eu gostei do DEVAGAR. “DEVAGAR & SEMPRE”, como naquela fábula da tartaruga. Taí, já arrumei até mascote para o ‘business-centric’…

    .:.

    Notas:

    1. Os princípios desenham o perfil de um processo. Quanto mais genéricos forem, mais maleável é o processo. Por isso é preciso ter muito cuidado com processos que se apresentam como de uso geral, mas apresentam princípios que, de certa forma, são ‘intrusivos’. Reparem: trata-se de uma crítica que se aplica à listinha DEVAGAR acima. Com certeza ela não atenderá qualquer tipo de negócio. O que dizer então de projetos?
      O mais importante é ter um bom ponto de partida. E ninguém pode ensiná-lo melhor do que seu próprio negócio.
    2. Object Solutions – Managing the Object-Oriented Project
      Grady Booch. Addison-Wesley (1996).

    .:.

  • … E a inevitabilidade das Marés

    Série “De Brooks a Berkun” – 4ª Parte

    “O primeiro passo é aceitar as mudanças como um estilo de vida, e não como um desvio, uma exceção“. Assim, de forma simples e direta, Fred Brooks começa a tratar o tema “Mudanças”.

    Mudanças ocorrerão em um projeto não só porque o trabalho inicial (coleta e análise de requisitos e arquitetura da solução) não foi bem feito. Segundo Brooks, “a entidade Software está sempre sujeita a pressões por mudanças. Claro, como prédios, carros e computadores. Mas coisas manufaturadas raramente mudam após sua produção”. Já o software sim, dada sua “infinita maleabilidade”. Não carecemos nem mesmo das borrachas e marretas de Frank Lloyd Wright.

    “Longe de mim”, diz Brooks, “sugerir que todas as mudanças de objetivos do cliente podem ou devem ser incorporadas ao desenho da solução. Um delimitador deve ser estabelecido, e ele deve ficar mais restritivo na medida em que o desenvolvimento avança, ou o projeto nunca terminará”.

    O delimitador parece óbvio na teoria, mas é peça rara na prática. Se a mudança solicitada for crucial para o pleno atendimento das necessidades de negócio, o que fazer? Ignorá-la? Dizer que ela será implementada na ‘2ª versão’? Toda solicitação de mudança deve ser analisada com carinho, independente do que esteja indicando o termômetro do projeto. Independente da fase do projeto e da fase da lua.

    Para Scott Berkun toda solicitação de mudança deveria seguir o mesmo processo de negociação que guiou a fase inicial de coleta de requisitos. Creio que a assimilação do processo se torna mais simples se entendermos que toda solicitação de mudança nada mais é que um novo requisito. Ou, em muitos casos, uma ‘nova versão’ de um requisito. Quando executamos corretamente a Engenharia de Requisitos, avaliamos os impactos que cada nova solicitação pode causar naquelas previamente coletadas. Agora, recebendo um change request, executaríamos o mesmo tipo de análise. Dependendo do porte do projeto e do número de dependências (grau de ‘acoplamento’) dos requisitos, tal avaliação pode ser penosa e demorada. É inevitável? Berkun sugere um breve check-list para uma avaliação prévia dos requisitos que apareceram ‘fora de hora’:

    • Qual problema estamos tentando resolver? Precisamos resolvê-lo para obtermos sucesso? Precisamos resolvê-lo na iteração atual? Podemos viver com o problema?
    • Trata-se de um sintoma ou uma causa? É aceitável que tratemos apenas o sintoma?
    • Temos noção do impacto desta mudança?
    • O custo da mudança será compensado pelo benefício gerado?
    • E os riscos de novos problemas são compensados pelo benefício da mudança?

    A menos que a solicitação de mudança seja absurdamente ridícula, a execução do check-list acima não será rápida e muito menos trivial. Por isso cabem aqui dois alertas: i) O cliente, ou usuário ou o stakeholder-Zezinho que solicitou a mudança deve participar do processo acima. Ele precisa ter noção do ‘estrago que está prestes a causar’. E ser co-responsável por ele; e ii) O processo de desenvolvimento em uso (a metodologia) deve tentar programar o momento certo para a avaliação das mudanças solicitadas. Como foi apresentado na 1ª parte desta série, quanto maior a incerteza (a volatilidade dos requisitos), menor deve ser a duração de uma iteração. No mundo ideal, todas as solicitações de mudanças são analisadas no momento em que a equipe planeja a próxima iteração. Se uma triagem foi executada anteriormente pelo coordenador ou analista de negócios, em conjunto com o Zezinho, então não é o mundo ideal. É o paraíso mesmo.

    Scott Berkun apresenta então uma forma muito simples de gestão de mudanças, que ele chama de “versão super-lean do processo de especificação”. Consiste do seguinte:

    1. O Coordenador do Projeto (ou o Analista de Negócios – interferência minha), escreve um sumário da mudança solicitada, incluindo sua relação com os objetivos do projeto e com os requisitos previamente apresentados; justifica a necessidade da mudança; e apresenta o desenho da mudança a ser implementada. Berkun sugere que este documento tenha no máximo duas páginas;
    2. O programador, o testador e todos significativamente impactados pela solicitação devem analisar o documento gerado e dar suas contribuições. As mais notáveis (e ansiosamente aguardadas por todos) são as estimativas de desenvolvimento e testes.
    3. O documento finalmente é apresentado aos líderes do projeto (e, como sugeri anteriormente, ao cliente, usuários, zezinhos etc). Nessa breve reunião a mudança é aceita ou não. Se recusado, diz Berkun, “o documento deve rastejar até o canto mais próximo e, soluçando incontrolavelmente, desaparecer do universo do projeto”.

    Insisto que a reunião citada no item 3 acima deveria ser programada e tratar de um pool de solicitações de mudanças. Se executada ad hoc e a granel, se transformará rapidamente no ‘inferninho’ do projeto.

    Fred Brooks cita um estudo de Lehman e Belady que mostra que em cada nova versão o número de novos módulos cresce linearmente, mas o número de módulos afetados pelas mudanças aumenta exponencialmente. Todas as correções e alterações de rumo (em relação à arquitetura original) “tendem a destruir a estrutura, a aumentar a entropia e desordenar o sistema”.

    O divisor de águas, a separação entre marés (mudanças) ‘benéficas’ e tsunamis ‘detonantes’, deveria ser mais nítido. Mas a prática prova que não é. Está no discurso de todos os processos modernos que devemos ‘aceitar as mudanças’. Afinal, elas são inevitáveis. Mas sabemos que alguns change requests podem simplesmente inundar o projeto com efeitos colaterais mortais. O que permite sua distinção? Como avaliar corretamente o impacto e os riscos de uma mudança? Creio que é impossível sem uma clara visão da arquitetura do sistema. Um modelo detalhado, que exponha todas as interfaces entre todos os módulos, parece ser a melhor vacina contra mudanças maléficas. Mas um modelo só mede o impacto das mudanças na arquitetura do sistema. E os planos, cronogramas, agendas e finais de semana prolongados? Como ficam?

    Planejar ou não Planejar? É uma questão?

    Apesar de demonstrar uma certa simpatia por XP (eXtreme Programming) e suas breves iterações, Berkun reforça a utilidade dos planos de longo prazo: “mesmo quando eles são grosseiros, eles tornam as mudanças de curto ou médio prazos mais fáceis”. E justifica: “quando uma mudança nos objetivos, requisitos ou no design ocorre, raramente o plano original vai parar na lixeira”. O plano original talvez seja nossa melhor (senão única) base de comparação para uma correta avaliação das mudanças propostas. Berkun cita Dwight D. Eisenhower:

    “Nenhuma batalha é vencida de acordo com um plano, mas nenhuma batalha é vencida sem um.”


    Berkun (e mais um monte de gente) gosta de comparar Projeto com partidas de xadrez. Tanto que o capítulo de seu livro que trata de forma mais específica o tema mudanças chama-se “Middle-Game Strategy”. Cada decisão do gerente do projeto, assim como cada movimento de um enxadrista, só pode assumir uma de duas características possíveis:

    • Conservadora: deixa-o com o maior número possível de ‘movimentos futuros’, de opções. Em um projeto pode significar uma desaceleração do ritmo. Mas, escreve Berkun, “este é o preço do seguro que você está comprando”.
    • Agressiva: mostra total domínio e comprometimento com uma estratégia. O gerente confia em seu plano e em sua ‘força’.

    A ausência de um plano não permite nem mesmo avaliar o perfil das decisões do gerente do projeto. E a maneira como elas são apresentadas pode ser um péssimo indicador. Lembra aquela piada do marido que diz sempre ter a última palavra em casa: ‘Sim senhora!’.

    Para Scott Berkun o Gerente que tem total controle do projeto está sempre ‘um passo à frente’. Para tanto ele sugere a realização de dois check-lists para a verificação de nossa sanidade, digo, da sanidade do projeto. O primeiro é tático (diário), e apresenta as seguintes questões:

    • Quais são nossos objetivos e compromissos? Eles ainda são válidos?
      No meio de tanto trabalho, diz Berkun, “é muito fácil perder os objetivos de vista”. Olhar para eles diariamente é uma forma de manter o foco e avaliar corretamente as prioridades.
    • O que estamos realizando hoje contribui para a realização dos objetivos?
      É claro como os trabalhos em execução contribuirão para a satisfação dos objetivos e dos requisitos? Se não, diz Berkun, “o barco tá começando a ficar à deriva”.
    • Os trabalhos estão sendo concluídos de forma a satisfazer os requisitos e cenários?
      “Há mil maneiras de completar uma unidade de trabalho que não satisfaz o espírito e a intenção do design“, lembra Berkun. Sabemos que a distância entre o “tá pronto” do programador e o “tá pronto” do usuário pode ser quilométrica.

    O outro check-list é estratégico e, segundo Berkun, deveria ser executado semanalmente ou mensalmente, seja em reuniões de discussão do status do projeto ou mesmo individualmente. As questões são:

    • Qual a probabilidade de atingirmos o próximo milestone com o apropriado nível de qualidade?
      Com certeza aconteceram mudanças desde o trabalho de estimativas. E mesmo que não, não custa nada perguntar ao time se o cronograma segue verdadeiro e exequível.
    • Quais ajustes são necessários para aumentar tal probabilidade?
      Berkun diz que “é raro obter 100% de confiança na próxima data de qualquer um que seja honesto e são”. Portanto esta pergunta (quase) sempre será colocada.
    • Como executar tais ajustes com cuidado e de forma isolada?
      “Um telefonema? Um email? Despedindo alguém?”. Berkun alerta que devemos pensar de forma ‘cirúrgica’, mas não devemos temer as ações e decisões que precisam ser executadas/tomadas.
    • Quais são os maiores ou mais prováveis riscos que enfrentamos hoje, na próxima semana ou no próximo mês? E quais são as contingências?
      A simples identificação dos maiores ou mais prováveis riscos já é, de acordo com Berkun, um grande passo no sentido de prevení-los.
    • O mundo mudou e eu não estou sabendo?
      Os patrocinadores ainda são os mesmos? E seus objetivos, mudaram? O time se preocupa com algo que eu não conheço? Nossas antenas e sentimentos devem estar atentos para mudanças que ocorram tanto no micro-universo quanto no macro-universo do projeto.

    Na sequência do mesmo capítulo de “The Art of Project Management”, chamado “Middle-Game Strategy”, Scott Berkun apresenta várias outras ‘ferramentas’ para o (micro) gerenciamento (diário) do projeto. Brinquei com os parênteses para destacar a mensagem: gerenciar um projeto significa (tentar) cuidar de um número imenso de varíaveis, a maioria delas muito pequena e volúvel, durante todo o dia. Todos os dias.

    ===

    1. Lehman, M. e Belady, L, “Programming System Dynamics”, ACM SIGOPS (1971).