finito

Categoria: Biblioteca

Dicas de livros e outras referências.

  • CRUISE: Primeiros Passos

    Em uma das partes da série que desenvolvo sobre Ativos de Sofware e Reuso eu comentei minha estranheza em relação ao trabalho do RiSE (Reuse in Software Engineering), um grupo do CESAR (Centro de Estudos e Sistemas Avançados do Recife). Fiz contato com o grupo tentando obter referências e dicas. Um membro me direcionou para o site do IEEE (onde eu deveria comprar as tais referências!).

    Estranhei porque, salvo engano, parte da grana que sustenta o CESAR é pública. Mesmo que eles fizessem da venda de artigos uma fonte de receita alternativa, não faz sentido que a venda seja feita em dólar e intermediada por uma entidade dos EUA. Não entendi e também não obtive nenhum tipo de retorno. Ok. Registrei a crítica e esqueci a questão.

    Mas eis que agora recebo a notícia do lançamento do CRUISE (Componente Reuse in Software Engineering), uma compilação dos achados do RiSE. O livro foi lançado sob licença Creative Commons (by-sa-nc) e, claro, é distribuído gratuitamente. A porta que parecia fechada a 7 chaves agora está escancarada (no melhor sentido).

    Ainda não tive a chance de ler o livro – acabo de baixá-lo. Mas creio que será muito útil na conclusão do meu trabalho. Um trabalho que pode ganhar novo rumo: o pessoal do RiSE, com o lançamento do livro, convoca-provoca participações. Reclama inclusive que nosso meio acadêmico deveria ter mais iniciativas como essa.

    Jóia. Mas como tenho que manter minha reputação de “muito chato”, antecipo aqui uma crítica: por que em inglês? Sei que existirão mil justificativas do tipo: “é nossa língua universal!”. Sorry (haha).

    Nossa língua oficial é o português. Todo trabalho gerado em universidades públicas deveria estar em sua língua oficial. Depois viriam as traduções. Engraçado é que no e-mail de divulgação eles falam: “contribuições para melhorar a versão original são muito bem vindas. Inclusive porque inglês não é a língua nativa de nenhum dos autores.” Dá pra entender?

    De resto, agora é mergulhar no texto, aprender (muito) e colaborar (sempre que possível). Pela iniciativa, parabéns ao pessoal do RiSE. Que seu exemplo seja seguido por muitos.

  • Meme #014 – Tecnologia é só 1% da Solução

    Qualquer combinação de software e hardware pode ser vista como um sistema de informação que pode ser dividido, literalmente, no sistema propriamente dito e a informação, suas propriedades e contexto que trata (incluindo aí regras de negócio, gente, problemas, oportunidades…).

    O sistema, por sua vez, é uma composição das tecnologias usadas para sua construção e a capacidade de aplicação das mesmas em um dado ambiente de informação. O que normalmente significa que um grande especialista em sistemas financeiros, por exemplo, vai estar perdido se o problema à sua frente for desenvolver um sistema de e-mail. Depois de quase 30 anos fazendo software, acho que descobri as porcentagens que regem as divisões acima: um sistema de informação é 10% sistema e 90% informação. E o sistema é 10% tecnologia e 90% aplicação, o que faz com que a tecnologia, de fato, seja apenas 1% da solução.

    – Sílvio Meira (em “Mudando o Mundo. Como?“)

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Meme #013 – O Ócio Lubrifica

    Slack at all levels is necessary to make the organization work effectively and to grow. It is the lubricant of change. Good companies excel in the creative use of slack. And bad ones can only obsses about removing it.

    – Tom DeMarco (em “Slack”)

    Surrupiei a citação deste excelente artigo do Maurício Linhares. Cheguei até ele via Fragmental.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Meme #012 – O Cliente está sempre Conectado

    “I think that right now we’re at a stage where the tools and accepted architectures do not fit the job that programmers have to do. We have three factors that are not going to change in the near future, and they all live on the client: HTML, the browser, and Javascript. Everything else is negotiable. It’s up to programmers to figure out how to deliver the best application they can using any back-end they want, as long as it works with those three front-end technologies. Programmers have done some really cool stuff on top of those three technologies, but things are still pretty awkward.”

    …

    “The big problem, I think, is that the front-end is still very disconnected from the back-end. Because of SOA, people are still thinking very much in terms of sending and receiving messages rather than thinking about how to create a smooth and seamless application that exists both on the client and the server. I don’t know if it’s because of the fact that the Web was very disconnected in the early days, but most programmers still don’t think of the Web browser as a connected client.”

    …

    “However, there is no longer any good reason to keep the client disconnected from the server in terms of software architecture. Broadband penetration is now 75% of active Internet users in the U.S., and much higher in countries that are not as backwards as we are. For some reason, programming techniques have not yet adapted to this fact. And what’s more, everyone is on their way to becoming an always-on node on the Internet network. One third of Blackberry owners are not using their phones for business. The iPhone from Apple (if it gets to keep its name) is a tiny OS X computer with Internet connectivity. In places where Wi-fi hotspots aren’t present, Wi-Max will be soon. In other words, we can no longer get around the fact that the client is once again part of the architecture equation, and our programming practices need to support that fact.”

    – Jason Kolb (em “Network-Oriented Architecture“)

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Meme #010 – SOA não é Futuro

    A impressão que tive é que com a quantidade de dinheiro que se está investindo em SOA hoje não dá mais pra chamar de futuro, mas de presente. Claro que há um problema muito grande aí: Este foi o mesmo cenário, por exemplo, com EJBs.

    Eu espero sinceramente que tenhamos aprendido a lição e que estudemos os conceitos por trás das coisas antes de sair por aí implementando sistemas que não funcionam utilizando ferramentas caríssimas.

    – Philip Calçado (em seu blog Fragmental)

    ===

    Acabei de conhecer o trabalho do Philip. Coisa muito boa, escrita d’uma forma muito legal. Tanto que já tá devidamente assinado e referenciado ali embaixo.

    E assim retomo os posts “meme” aqui no finito.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • A Receita e o Bolo de Fubá

    Série “De Brooks a Berkun” – 5ª e última parte.

    Quando pensei no título desta última parte da série busquei algo que fosse extremamente simples, uma receita culinária de um prato bem ‘default’. Mas que ao mesmo tempo parecesse único em cada ‘fornada’. O bolo de fubá foi uma lembrança imediata. Nunca vi dois iguais. Mais seco, mais molhado, dois ou quatro ovos, com queijo ou não… com vinagre!?! Pois é, achei mais de 30 mil ocorrências para “bolo de fubá” no Google. Minha família (mineira, obviamente) compartilha uma mesma receita. Mas o resultado é sempre diferente. Para algo que deveria ser incrivelmente simples: são só meia dúzia de ingredientes. Um mesmo processo. Um mesmo cronograma. Mas, surpreendente mesmo é a ilusão que todos nós que lidamos com desenvolvimento de sistemas já alimentamos pelo menos uma vez na vida: a ilusão de que existiria uma receita mágica, uma “bala de prata”, que nos ajudaria a entregar nossos projetos no prazo, dentro do orçamento e excedendo todas as expectativas de nossos clientes e usuários.

    Se é quase impossível reproduzir com exatidão a simplicidade de um bolo de fubá, o que dizer de nossos projetos para desenvolvimento de software?

    Em 1986 Fred Brooks publicou o artigo “No Silver Bullet”, que aparece como o capítulo 16 na edição de 20º aniversário de “The Mythical Man-Month”. No texto ele previa que em um horizonte de 10 anos não apareceria nenhuma evolução, nem tecnológica nem gerencial, que promoveria ganhos consideráveis de produtividade e confiabilidade. “Ceticismo não é pessimismo”, Brooks frisava. Nove anos depois, para a edição comemorativa, ele escreveu “‘No Silver Bullet’ Refired”, seu 17º capítulo. Responde algumas críticas e conclui que estava certo em sua avaliação.

    Uma avaliação que pode ser resumida em uma frase apenas: “Construir software será sempre difícil“. Brooks fundamenta sua tese apresentando quatro propriedades (“irredutíveis”) da ‘entidade’ software:

    • Complexidade: uma propriedade essencial, não acidental. Ou seja, software é uma entidade complexa por natureza, “talvez a mais complexa de todas as construções humanas”. De tal complexidade vem a dificuldade de comunicação entre os membros do time; dela deriva a impossibilidade de enumerar ou mesmo compreender todos os estados de um programa, e daí vem a falta de confiança. É da complexidade da estrutura que vem a dificuldade de se criar novas funcionalidades que não resultem em efeitos colaterais indesejados. Em suma e para usar um termo bem nosso, tupiniquim: Software é um “bicho de sete cabeças”. Ponto.
    • Conformidade: “grande parte da complexidade que deve ser dominada pelo engenheiro de software é arbitrária, forçada sem rima ou razão pelas diversas instituições humanas e outros sistemas os quais suas interfaces devem conformar. Isso muda de interface para interface, de tempos em tempos, não apenas porque há uma necessidade, mas porque as interfaces são desenhadas por pessoas diferentes”.
    • Instabilidade (de changeability): “A entidade software está constantemente sujeita a pressões por mudanças”. “Software pode ser alterado facilmente – ele é infinitamente maleável”.
    • Invisibilidade: abstrações geométricas são muito úteis, mas não conseguem representar toda a complexidade de um software.

    Brooks lista então uma série de avanços que podem ajudar a melhorar a qualidade de nossos projetos. Mas frisa que nenhum deles é uma “bala de prata”: Linguagens de alto nível (ele cita Ada – lembrem-se, o artigo é de 1986); Orientação a Objetos; Programação ‘Automática’; Programação ‘Gráfica’; etc. Na sequência ele lista alguns princípios que podem ‘atacar diretamente’ a essência dos problemas com software:

    • Comprar ao invés de Construir: “a solução mais radical para os problemas com a construção de software é não construí-los”. De certa forma as ondas ERP e CRM livraram várias empresas de grande parte do peso da construção e manutenção de sistemas. Mas todas as organizações ainda demandam soluções específicas. Se não as constroem internamente, contratam serviços de desenvolvimento. Não acredito que um dia será possível comprar ‘pacotes’ (ou componentes ou serviços) para todo e qualquer tipo de problema de negócio.
    • Refinamento dos Requisitos e Prototipação Rápida: “a parte mais difícil da construção de software é definir precisamente o que construir”. “Creio que é impossível para os clientes, mesmo aqueles que trabalham ao lado dos engenheiros, especificar completamente, precisamente e corretamente todos os requisitos do software antes de experimentar algumas versões”. Portanto, segue Brooks, “um dos mais promissores avanços é o desenvolvimento de métodos e ferramentas para a prototipação rápida de sistemas como parte do processo iterativo de especificação dos requisitos”.
    • Desenvolvimento Incremental: ‘aumente’ (cresça) um software, não construa (no texto original, “grow, not build, software”). Para Brooks a metáfora da construção já deu o que tinha que dar. “Vamor olhar para a natureza e estudar a complexidade dos seres vivos ao invés dos trabalhos ‘mortos’ do homem”. Este princípio pode ser aplicado tanto no ciclo de vida do projeto quanto no ciclo de vida do próprio produto. Processos iterativos e incrementais já são comuns. Quase ‘carne de vaca’. O que é novo é a forma como o Google, por exemplo, ‘cresce’ e evolui seus serviços. Não se trata meramente de uma ‘manutenção’, e eu acredito que muitos de nossos produtos podem ganhar com esse novo enfoque. Independente do público e da tecnologia, diga-se de passagem.
    • Grandes Designers: “Grandes projetos (designs) vêm de grandes arquitetos (designers). A construção de software é um processo criativo. Uma boa metodologia pode fortalecer e liberar uma mente criativa; mas não pode inflamá-la ou inspirá-la”. Brooks conclui: “a principal questão para a evolução da arte do software está centrada, como sempre esteve, nas Pessoas“. Não é por acaso que Brooks encerra seu livro recomendando a leitura de “Peopleware” , de Tom DeMarco.

    Receitas, Metodologias, Processos…

    E não parece ser uma mera coincidência que Scott Berkun inicie seu livro citando… “Peopleware”, de Tom DeMarco:

    “A obsessão com metodologias é outra instância da ilusão high-tech. Deriva da crença de que o que realmente importa é a tecnologia…
    Independente de qual seja o avanço tecnológico, ele cobrará seu preço com a deterioração da sociologia do time.”

    Para Berkun, “a pior coisa é seguir cegamente um conjunto de regras e procedimentos só porque eles apareceram em um livro famoso ou porque são promovidos por um respeitado guru”. Berkun coloca que processos e metodologias são muito importantes, mas nunca serão ‘balas de prata’, entregadores de projetos bem sucedidos. E alerta para o perigo dos gerentes, em determinado momento de um projeto, “começarem a acreditar que o Processo é o Projeto”. Pode parecer absurdo, mas este ‘desvio’ é mais comum do que se imagina.

    Um bom processo, segundo Berkun, apóia as pessoas e amplifica o seu valor. E seria o resultado da combinação de duas coisas: i) o que torna projetos e times bem sucedidos de uma maneira geral; e, ii) o que torna o projeto e o time atuais diferentes dos outros.

    Eu gosto de acrescentar uma terceira variável, tão importante quanto o projeto em si e o time, no momento da seleção/customização de um processo: o Cliente. Quando se trabalha na indústria, como é o caso de Berkun, raramente se dispara um projeto para um cliente específico. Daí sua omissão. Mas no mercado de prestação de serviços de desenvolvimento é altamente recomendado que o perfil (valores e a cultura) do cliente seja levado em consideração no momento da customização do processo. Em alguns casos o próprio cliente solicita a incorporação de alguns métodos e artefatos, quando não a adoção de um ciclo de vida específico.

    Mas o importante aqui é entender que não existe e nem nunca existirá uma ‘metodologia mágica’, aplicável em vários projetos. Cada projeto exigirá um processo específico. Mas isso não significa que a organização sempre partirá ‘do zero’. Muito pelo contrário. A primeira variável colocada por Berkun acima é “o que torna nossos projetos e times bem sucedidos de uma maneira geral”. Trata-se de um corpo de conhecimentos único, exclusivo. E orgânico, já que o natural é que ele cresça e fique mais rico a cada projeto. Infelizmente, quando olhamos algumas particularidades do mercado brasileiro de prestação de serviços de desenvolvimento, percebemos que muitas empresas dão pouquíssimo valor para esse aprendizado, lançando mão de vínculos empregatícios muitos frágeis (PJs e afins), o que resulta em uma alta rotatividade de seus colaboradores. Há quem acredite que este tipo de conhecimento pode ser capturado e aprisionado em documentos e coisas do tipo. Não é o meu caso. A explicitação de conhecimentos, sua compilação em artefatos que podem ser recuperados a qualquer momento, é benéfica para todas as organizações. Mas não consegue representar nem um pequeno pedaço de toda a experiência adquirida por um time durante a execução de um projeto. Trata-se de outra ‘ilusão high-tech‘, para usar um termo do DeMarco, que tenta impedir que o peopleware tenha seu valor reconhecido.

    Voltando ao Berkun. Logo no início de “The Art of Project Management” ele ensina três ‘lições-chave’ que guiam boa parte de seus métodos, guias e sugestões. São elas:

    • Gerenciamento de Projetos e Desenvolvimento de Software não são artes sagradas: apesar do ar de ‘novidade’ que impera em nossa área, é crucial lembrar que existem ensinamentos que podem vir de outros lugares.
    • Quanto mais simples for a sua visão do que você faz, mais poder e foco você terá em sua execução: estar sempre curioso e aberto à novas idéias é o que torna o crescimento possível. Uma visão simples de nosso trabalho pode facilitar sua comparação com outras coisas que existem ao nosso redor. Aumentamos assim a possibilidade de aprendizagem.
    • Simples não é sinônimo de fácil: correr uma maratona é simples, certo? Basta começar a correr e não parar até alcançar o quadragésimo kilômetro. Você diria que é fácil? Liderança e gerenciamento também são difíceis, mas sua natureza – realizar coisas de determinada maneira atrás de um objetivo específico – é simples. Bolos de fubá e pães de queijo também são extremamente simples. Não consigo entender porque só aqui em Minas eles são realmente gostosos.

    Epílogo

    Encerro assim uma série de 5 partes (9 artigos separados) que iniciei com a intenção de homenagear Fred Brooks e sua obra prima, “The Mythical Man-Month”, e também para apresentar o ‘caçula dos gurus’ (ele detestaria o rótulo), Scott Berkun. Como eu disse lá no início da viagem, estes artigos não substituem de forma alguma o prazer de ler os dois livros. E, posso garantir, não cobrem nem 10% de seu conteúdo.

    O retorno que eu recebi (infelizmente a maioria foi off-blog) compensou com sobras o trabalho. O próprio Scott Berkun deu uma olhada no trabalho. E comentou:

    “I did read the tribute you wrote and was flattered by it. I wouldn’t compare myself to Brooks – maybe if in 25 years ‘the art of project management’ is even still in print can a few modest comparisons begin.”

    Apesar de não concordar com minha comparação, Scott me presenteou com uma cópia autografada de seu livro. Ah, se ele soubesse como torço para que seu livro não permaneça atual daqui 25 anos. A longevidade do livro de Brooks indica, de certa forma, que não aprendemos muito. Ou que não aprendemos direito. Eu sinceramente gostaria que ambos se transformassem em relíquias, documentos de um tempo em que a gente estava brincando de aprender a desenvolver software e a gerenciar projetos.

    O próximo passo, ensinou Brooks, é aceitar que “software é um dos mais complexos trabalhos manuais do homem. Tal complexidade demanda nosso contínuo aprendizado, a melhor utilização das novas ferramentas, uma melhor adaptação a métodos gerenciais, a aplicação do bom senso e, acima de tudo, humildade para reconhecer nossas falhas e limitações“.

    ===

    1. Tom DeMarco e Timothy Lister, “Peopleware – Productive Projects and Teams”, 2ª edição – Dorset House (1999, 1987).

    ===

    Créditos e Considerações Finais

    As imagens utilizadas na abertura de cada capítulo da série são de Chema Madoz, fotógrafo espanhol que não faz nenhuma questão de esconder sua maior influência, o louco mestre Salvador Dali. Os puristas podem reclamar dos indevidos ‘mashups’ que fiz nas imagens. Entendam como sendo uma forma de forçá-los a visitar o belo site de Chema, onde as imagens podem ser vistas em seu formato original.

    As demais imagens, diagramas rabiscados, foram surrupiados digitalmente de “The Art of Project Management”. Aliás, boa parte das fotos presentes no livro são do próprio Scott Berkun.
    Que faz uma coisa que nunca vi em livros técnicos: lista os sons que ‘mantiveram sua sanidade’ durante as longas horas em frente ao micro. De Charles Mingus a Aimee Mann, passando por Beatles, Clash, Radiohead e Audioslave. O cara escuta de tudo. E tem bom gosto.

    Jonas Fagundes, J. Werther, Roberto, Régis, José Papo, Ivo Michalick e outros amigos ‘ocultos’ deixaram sua contribuição, na forma de comentários neste blog ou no grupo de discussão CMM-Brasil. Muito obrigado a todos. Se você curte o tema e procura um bate-papo de alto nível, o grupo é uma grande pedida.

    Guz Vasconcellos fará a revisão do texto antes de sua conversão para um arquivo PDF. O blog manterá a (bugada) versão original.

    That’s all, Folks?

    Claro que não. O finito seguirá com um artigo por semana, sempre girando em torno dos temas Engenharia de Software, Gerenciamento de Projetos, Arquitetura de Soluções, e tudo o mais que caiba neste ‘torto’ triângulo. Sugestões de temas? Quer trocar idéias? Levar palestras e workshops para sua escola ou empresa? Demorou!

    Ops… err… Vc fez uma busca por ‘bolo de fubá’ e caiu aqui por engano? Ou então ficou morrendo de curiosidade? É o seguinte:

    Ingredientes:
    4 ovos
    4 copos de leite
    1 xícara e meia de açúcar
    1 xícara e meia de fubá
    2 colheres de sopa de manteiga
    2 colheres de sopa de farinha de trigo
    1 colher de sopa de fermento em pó
    1 xícara de queijo (canastra ou parmesão) ralado
    1 pitadinha de sal

    Preparo:
    Em uma vasilha misture os ovos, acrescente o leite e aos poucos coloque o fubá misturando bem. Coloque o açúcar, o sal, a manteiga e misture novamente. Junte a farinha de trigo e por último o fermento em pó. Leve ao liquidificador, batendo por alguns minutos. Volte com a massa para a vasilha e acrescente o queijo ralado.

    Despeje numa fôrma untada e leve ao forno quente por mais ou menos trinta minutos.

    Se vai ficar bom como o da minha Vó eu não posso garantir.
    Não existe receita mágica, certo?

  • … 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).

  • Vai entender o que o Cliente quer

    Série “De Brooks a Berkun” – Continuação da 3ª Parte.

    Scott Berkun dedica várias páginas de seu livro para tratar da tal ‘Engenharia de Requisitos’ (termo que ele não utiliza) e do ‘Design’ (termo que ele usa insistentemente) de uma solução. Capítulos como “How to figure out what to do“, “Where Ideas come from” e “What to do with ideas once you have them” dão o merecido tratamento aos temas.

    Para Berkun, a Perspectiva do Cliente pode ser obtida de duas formas: Requisitos e Pesquisas. E sugere que para cuidar das funções relacionadas à esses tipos de levantamentos deveríamos alocar dois tipos de experts: Engenheiros de Usabilidade e Designers de Produtos. Mas Berkun observa: “Mesmo que na última década muito progresso tenha sido feito no refinamento de métodos de pesquisa e compreensão de clientes, grande parte dele não foi assimilado pelo corpo gerencial – ou em organizações centradas na engenharia. Ainda é incomum que times de projetos tenham um expert em pesquisa de cliente, design de interfaces e usabilidade disponibilizado para os tomadores de decisão”. Na sugestão que apresentei na 2ª parte desta série, o Desenvolvedor de Interfaces realiza tais funções. Trabalhando bem próximo do Analista de Negócios.

    Muito se fala, e eu não tenho dúvidas, de que o tema ‘requisitos’ responde por mais de 50% dos problemas em nossos projetos. Berkun nos apresenta 5 dicas para a obtenção do que ele chama de “Requisitos de Alta Qualidade”:

    • Planeje as negociações de requisitos e as iterações
      Identificados nossos clientes e demais atores do projeto, torna-se factível a elaboração de uma Agenda para a Coleta de Requisitos. No pior cenário, uma RFP deve dar pistas suficientes para o rascunho de um plano inicial.
    • Elimine as Suposições Erradas
      Como identificá-las? Só perguntando. Como diz o Berkun, “se você é o coordenador do projeto … religiosamente faça perguntas esclarecedoras, como ‘por que precisamos disso?’, ‘que problema isso resolve?’”, e assim por diante. Só não permita que seu time assuma como verdadeiras solicitações que podem nem mesmo ter partido do cliente, ou dos verdadeiros usuários.
    • Busque as Informações que Faltam
      “Os mais notáveis erros em requisitos são erros de omissão”. A coleta e análise bem realizadas devem tornar bem visíveis todas as peças que faltam no tabuleiro do projeto.
    • Defina Prioridades Relativas para todos os Requisitos
      Costumo solicitar, ainda na coleta, que o cliente/usuário defina se aquela solicitação é Fundamental, Importante ou Opcional. Uma classificação clara e simples assim ajuda muito em diversas tomadas de decisão.
    • Refina ou Elimine a Linguagem Ambígua não-Intencional
      “Palavras como rápido, grande, pequeno, bonito e usável requerem métricas relativas para serem entendidas. Em alguns casos, pode ser do interesse de todos que elas permaneçam ‘em aberto’ até momentos posteriores do projeto”. Mas, a princípio, devemos eliminar toda redação que não permita um entendimento único de um requisito.

    Cabe aqui outra intromissão minha. Ainda há muito trabalho a ser realizado antes do Analista de Negócios repassar os requisitos para o time de Arquitetura da Solução. As dicas do Berkun listadas acima são úteis mas não suficientes. No meu ponto de vista, todos os requisitos coletados devem ser estruturados, formando uma ‘base de conhecimentos’. Existem algumas ferramentas desenhadas especificamente para isso. Mas o mais importante é o modelo da base. Nesta palestra, já meio velhinha (apresentada em 2003 em evento da SUCESU/PMI), apresento uma sugestão de um modelo ‘mínimo’. Em “Requirements-Led Project Management”, de Suzanne Robertson e James Robertson, há um modelo um pouco diferente, que eles chamam de ‘Requirements Knowledge Model‘. Uma base persistida em um gerenciador de bancos de dados, ao invés de documentos textuais ou planilhas eletrônicas, é mais gerenciável. Fica mais fácil manter a tal rastreabilidade bi-direcional dos requisitos e também seu relacionamento com todos os demais artefatos produzidos no projeto.

    Uma vez gravado, um requisito nunca mais pode ser deletado. Parece boba, mas se trata de uma regra fundamental. Cada mínima alteração na redação do requisito ou em algum de seus atributos significa a inserção de um novo requisito, que substitui o anterior mas mantém um vínculo. Assim conseguimos rastrear todas as mudanças que ocorreram desde os instantes iniciais de um projeto. Portanto a ‘base de conhecimentos’ acaba se tornando um dos, senão o principal subsídio para o Gerenciamento de Mudanças (tema da próxima semana).

    Perdidos no Espaço (entre os Requisitos e a Solução)

    Constatação inquietante de Berkun: “Por razões que não consigo explicar totalmente, muitas pessoas têm dificuldade com o planejamento do trabalho criativo. Na maioria dos livros que li sobre gestão de projetos e desenvolvimento de software, há pouca cobertura sobre como sair de uma lista de requisitos do que deve ser implementado para um bom design. Cronogramas apresentam uma data para quando os requisitos supostamente estarão finalizados, e outra data para quando as especificações supostamente estarão prontas, mas poucas instruções são fornecidades para a execução daquilo que está entre essas duas datas”.

    Para Berkun, tão logo estejamos com os requisitos ‘no lugar’, “os designers podem explorar o território desenhado pelos requisitos. Há um largo espaço, chamado ‘Espaço do Problema’, de maneiras potenciais para resolver o problema colocado. Dependendo dos requisitos, este espaço pode ser bem grande; por exemplo, há um infinito número de possibilidades para se desenhar uma casa, um sistema de contabilidade, um web site ou seja lá o que for que esteja lhe pagando. Portanto, até que você tenha alguma noção das possibilidades que existem, não é muito esperto se comprometer com qualquer coisa descoberta nos momentos iniciais”.

    É a fase em que temos só uma folha ou um quadro branco. Brancos e vazios. É a fase das Idéias – apaixonante para alguns e apavorante para outros. As idéias vêm das pessoas, lembra Berkun: “nenhuma idéia na história da humanidade brotou de uma pilha de pedras, … , de livros de auto-ajuda, de seminários de criatividade ou de sessões de brainstorming“. Por que então a fase de design (Arquitetura da Solução) seria tão negligenciada? Para Berkun, “talvez seja porque as pessoas temem a exploração , especialmente quando estão sendo observadas”.

    Berkun diz ter “evidências irrefutáveis de que há um número infinito de idéias prejudiciais, horríveis, inúteis, comicamente estúpidas e embaraçosamente ruins”. Ele solta essa pérola ao questionar a máxima (segundo ele oriunda de comerciais de TV e de sessões de brainstorming – ou de comerciais de TV vendendo sessões de brainstorming) que diz que “não existem más idéias”. Lógico que elas existem. Aos borbotões. Dentre outras coisas, ele sugere algo muito simples: “Boas perguntas atraem boas idéias!”

    Para Berkun existem dois tipos de perguntas ‘Boas’ e um tipo de pergunta ‘Ruim’ quando estamos envolvidos em um trabalho criativo:

    • Perguntas Direcionadoras (Boas)
      “Chamam a atenção do time para algo importante, útil ou mesmo central para o trabalho em execução”. Tipo: Como o usuário saberá que deve clicar neste botão para ir para a próxima tela?
    • Perguntas Criativas (Boas)
      Ao contrário das questões direcionadoras, estas devem “levar o time para territórios ainda não explorados do problema em questão”. Algo como: Haverão outros meios para o cliente chegar na próxima tela?
    • Perguntas Retóricas (Ruins)
      “Gêmeas das questões criativas, diferenciam-se pelo fato de serem insinceras, perguntadas sem a intenção de se obter uma resposta”. Por exemplo: Aí ‘cai a ficha’ e o cliente de repente descobre que tem que ir para outra tela, certo?

    Mas, independente da qualidade (e da inteligência) de nossas perguntas, devemos esperar diversas idéias ‘ruins, comicamente estúpidas, hilariantes’ etc. Triste é o ambiente pouco tolerante a elas, porque, além de sisudo e monótono, inibe a participação de todos os membros da equipe, mina o espírito de colaboração que deveria existir durante todo o projeto. Além de desperdiçar boas piadas, né?

    Seguindo com Berkun: “É melhor que a gente suje as mãos e cometa vários erros nesta fase. Quanto antes isso acontecer, mais rápido a gente chega às boas idéias.”

    “As duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção”
    – Frank Lloyd Wright

    “A mais importante ferramenta do físico é sua cesta de lixo.”
    – Albert Einstein

    Berkun também detona outro ‘mantra’, comum em certos círculos por aí, o tal (sorry, mas só o vejo sendo usada em inglês): “think outside the box”. “Não é a eliminação das ‘caixas’ a parte mais difícil – é exatamente saber quais ‘caixas’ utilizar e quando. Restrições estarão sempre presentes”. E completa: “faça o que você quiser com a caixa. Pense dentro da caixa, fora da caixa, debaixo da caixa, corte-a e faça fogo com ela, qualquer coisa, desde que você gerencie para resolver os problemas identificados como críticos para o projeto”.

    O Problema do Tamanho do ‘Espaço do Problema’

    “Idéias fogem do controle”, diz o título de um sub-capítulo do livro de Berkun. Por isso, “se é difícil encontrar boas idéias, é muito mais complicado gerenciá-las”. Berkun diz que um erro muito comum é tratar o processo de design como se fosse um grande ‘interruptor’. Para ilustrar melhor a questão Berkun apresenta o gráfico abaixo:

    A partir de uma sólida base de (bons) requisitos, começamos a explorar alternativas de solução. Com o passar do tempo a tendência é que o número de alternativas (cenários) aumente. Aumentamos assim o tamanho do ‘Espaço do Problema’. Um dos riscos, segundo Berkun, é não saber o momento de parar com a geração de idéias e começar a filtrá-las. Para tal Berkun sugere a fixação de alguns pontos de checagem. Como ilustra o gráfico abaixo, são 6 os grandes check-points que deveriam nos guiar no processo de arquitetura da solução:

    1. Visão e Prova de Conceito
      Nosso ponto de partida deveria ser um documento de visão e uma prova de conceito. Traduzindo para Pindorama: será a tal ‘proposta técnica’ para muitos corajosos colegas.
    2. Agrupamentos de Idéias
      Depois de um certo tempo jogando conversa fora, digo, idéias ‘para fora’, é conveniente que elas sejam agrupadas e analisadas.
    3. Três Alternativas
      Naquele que deve ser identificado como ‘meio do caminho’ desta etapa do projeto, é indicado que a lista de alternativas seja filtrada, gerando de 3 a 5 alternativas mais viáveis.
    4. Duas Alternativas
      Pouco tempo depois deveríamos ser capazes de escolher apenas 2 alternativas de implementação.
    5. Um Design
      E então apenas um design (ou Arquitetura da Solução).
    6. Especificações
      Então, com a Arquitetura definida, geramos a especificação técnica da solução.

    Concordo com o que o Berkun disse em um dos trechos de nossa viagem pelos “Castelos de Areia”. Não é comum ver este tipo informação em livros de gerência de projetos e desenvolvimento de sistemas. Mas as “marés (mudanças) são inevitáveis”, não? Semana que vem conversamos sobre elas.

    ===

    1. Suzanne Robertson e James Robertson, “Requirements-Led Project Management“, Addison-Wesley (2005).

  • Castelos de Areia…

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

    Em 1986 Fred Brooks publicou o artigo “No Silver Bullet”, que aparece como o capítulo 16 da edição que comemorou os 20 anos de “The Mythical Man-Month”. Para Brooks, “ainda cometemos erros de sintaxe, com certeza, mas eles não são nada quando comparados aos erros conceituais da maioria dos sistemas”. Scott Berkun cita Brooks na abertura do capítulo “How to figure out what to do”, o terceiro de “The Art of Project Management”:

    “A parte mais difícil da construção de software é decidir o que construir. Nenhuma outra etapa do trabalho conceitual é tão difícil quanto a fixação dos requisitos técnicos detalhados, incluindo todas as interfaces com usuários finais, com máquinas e outros sistemas. Nenhuma outra etapa compromete tanto o projeto se executada erroneamente. Portanto, a função mais importante que o construtor de software executa para seu cliente é a extração iterativa e o refinamento dos requisitos do produto”.

    Para Brooks, trata-se de uma função que deveria ser executada por uma pessoa ou um grupo pequeno de pessoas. Seria, para ele, uma forma de garantir a ‘Integridade Conceitual’ de uma solução. A separação desta etapa, quando decidimos ‘o que deve ser construído’, da etapa de implementação, quando decidimos ‘como construir’, seria outra forma poderosa de buscar tal integridade.

    Berkun chama de ‘insanamente simples’ a forma como ele vê a etapa de planejamento de um projeto. Ela é representada no gráfico abaixo:

    E, seguindo em sua ‘insanidade’, Berkun justifica a necessidade de Planos. Segundo ele, os planos “funcionam como um remédio contra todo tipo de estupidez porque forçam que questões importantes sejam resolvidas enquanto há tempo para considerar outras opções”.

    Apesar de uma (sutil) diferença, ambos os autores concordam com a separação das fases de Domínio do Problema (ou ‘o que’, coleta de Requisitos, Definição etc) e de Domínio da Solução (ou ‘como’, design/especificação etc). Uma distinção óbvia, simples, mas deveras negligenciada. Quantas e quantas vezes testemunhamos ‘analistas’ (assim, entre aspas mesmo) discutindo ‘comos’ em dias iniciais de um projeto?

    Brooks radicaliza ao propor que o principal artefato gerado pelo Arquiteto de uma solução é o Manual, uma especificação de toda a parte externa de um sistema. É o manual do usuário mesmo, nas fases iniciais de um projeto! Um documento que não deveria se preocupar em explicar os ‘comos’.

    As Visões e o Documento de Visão

    Berkun é um pouco mais metódico e indica a necessidade de 4 documentos principais. Antes, porém, ele alerta para a criticidade do balanceamento de três perpectivas:

    • Negócio: “… quando equipes de engenharia ignoram como seu negócio funciona, muitas decisões da gerência parecerão ilógicas ou estúpidas”;
    • Tecnologia: “…é o mindset de construção e materiais. Tem o foco em ‘como’ as coisas devem ser feitas”;
    • Cliente: “A mais importante das três perspectivas… Mas, infelizmente, a mais fraca em muitas organizações.”

    Segundo Berkun, as três perpectivas sempre se sobrepõem. “Cada consideração ‘de negócio’ tem implicações Técnicas e para o Cliente (e assim por diante)”. E cada decisão pode favorecer determinado ponto de vista, em detrimento de outro. “Ao investir tempo explorando cada uma das perspectivas”, diz Berkun, “é possível ver oportunidades para melhores decisões estratégicas”.

    Para Berkun, a fase de planejamento de um projeto só se encerra quando os 4 documentos propostos por ele estão prontos. Ou, em suas palavras: quando “as decisões que eles contêm estão tomadas”. Os documentos são:

    • Marketing Requirements Document (MRD)
      Trata-se da ‘Visão do Mundo’ apresentada pelo negócio ou sua equipe de marketing. Apresenta os objetivos do negócio e ajuda a definir “o que” o projeto deve contruir visando sua satisfação;
    • Documento de Visão (Escopo)
      Define os objetivos do projeto, explica sua lógica e apresenta características (em alto nível), requisitos e datas. Definem diretamente “o que” o projeto deve realizar;
    • Especificações
      Define o “como” de um projeto, com uma perspectiva de design e engenharia;
    • Work Breakdown Structure (WBS)
      Mostra como o time trabalhará para realizar o projeto.

    Berkun também parece cair na ‘armadilha’ waterfall quando propõe que a fase de planejamento de um projeto só se encerra com a entrega (definitiva) destes 4 documentos. Apesar de indicar os aspectos iterativos e incrementais de sua elaboração. Não deveriam ser apenas os ‘acidentes’ (também conhecidos como ‘mudanças’) que nos forçam a voltar a tais documentos (tal fase).

    Se o MRD (que pode ser um RFP – Request for Proposal, por que não?) é (ou pelo menos deveria ser) elaborado pelo Cliente, temos que o primeiro documento confeccionado pelo time do projeto é o Documento de Visão. Segundo Berkun, além de apresentar e explicar todas as características (features) do produto a ser gerado, como no Manual sugerido por Brooks, o documento deve:

    • Explicar o projeto em apenas uma sentença (uma ‘declaração de visão’);
    • Mostrar como o projeto contribuirá para a satisfação dos objetivos do negócio;
    • Apresentar as características/cenários essenciais para os Clientes (prioridade 1);
    • Mostrar as características/cenários considerados ‘desejáveis’ mas não essenciais (prioridade 2);
    • Apresentar os clientes e os problemas que o projeto deve solucionar para eles;
    • Bem como apresentar os atores (stakeholders);
    • Explicar por que os clientes comprariam (ou alugariam) o produto do projeto;
    • Apresentar os concorrentes e uma comparação de seus produtos com aquele que o projeto deve gerar;
    • Explicitar o que está “fora do escopo” do projeto;
    • Mostrar quais os riscos do projeto;
    • Suas dependências externas (sub-contratados e afins);
    • Em alto nível, como o trabalho será organizado; e
    • Apresentar todas as suposições e dependências.

    Ou seja, o Documento de Visão, como proposto por Berkun, compila todas as informações e decisões elaboradas no planejamento inicial de um projeto. Esta compilação, escrita de forma a ser acessível/legível para todos os atores de um projeto, se torna um dos principais meios de comunicação/negociação com os clientes. Não entendo porque Berkun não sugere a inserção de um cronograma. Outra alteração que eu faria é a criação de uma ‘prioridade 3’, com a lista de todas as características/cenários classificados como ‘perfumaria’ ou supérfluos.

    Berkun sugere que 5 iterações seriam suficientes até a geração de uma versão final do Documento de Visão. Acho arriscado fixar assim o número de ‘versões’. Cada projeto pode determinar um ritmo/ciclo bastante particular. Mas creio que um mínimo de 3 iterações sejam necessárias. O trabalho nas Especificações e na WBS gerará, sem dúvidas, alterações na Visão.

    Por fim, Berkun destaca as 5 qualidades de uma “Boa Visão”:

    • Efeito “Simplificador”;
    • Apresenta de 3 a 5 objetivos de alto nível;
    • Consolidada;
    • Inspiradora; e
    • Memorável.

    O fato do autor, no caso Scott Berkun, manter um blog faz com que seu livro seja constantemente atualizado. Recentemente Berkun publicou um pequeno artigo chamado “Why vision documents stink“. Isso mesmo, ‘cheiram mal’. Ele comenta que em levantamentos informais, em suas palestras por exemplo, constatou que a grande maioria dos Documentos de Visão são muito ruins. Ele tem três teorias para o problema:

    • A falta de um ‘autor-líder’ que, no meu ponto de vista, deveria ser o próprio Arquiteto;
    • Os documentos não seriam escritos para servir ao leitor, denotando falta de compreensão e de interação com o cliente; e
    • A confusão entre ‘hype’ e realidade, que geraria documentos meio ‘marketeiros’ e pouco objetivos.

    continua…

  • Os Dois donos do Projeto (Totó)

    Série “De Brooks a Berkun” – Continuação da 2ª Parte.

    Fred Brooks encerra “O Time Cirúrgico”, terceiro capítulo de “The Mythical Man-Month”, falando que um sistema deve ter total Integridade Conceitual, e que isso só seria possível através da dedicação integral de um Arquiteto (System Architect, no texto original). Logo depois, em “Por que a Torre de Babel falhou?”, ele fala de dois líderes em um projeto: o Arquiteto (ou Diretor Técnico) e o Produtor. Mas o dito popular não ensina que “Totó com dois donos morre de fome”? Como um projeto pode ter dois líderes e não parecer uma organização confusa?


    Segundo Brooks, o Produtor é o cara que monta o time, divide as tarefas e elabora o cronograma. Também é ele quem cuida da aquisição de recursos durante todo o projeto. Portanto, na maior parte do tempo, o Produtor estaria interagindo com entidades externas ao projeto. Ainda assim, é ele quem estabelece padrões de comunicação e relatórios com o time.

    Já o Arquiteto (ou Diretor Técnico) é responsável pelo desenho do sistema a ser construído, seus módulos e também seu aspecto exterior. Interage principalmente com o time, resolvendo questões técnicas.

    Considerando que os dois perfis são necessários em projetos de qualquer porte, Brooks aponta três relacionamentos possíveis entre eles:

    • Arquiteto e Produtor são a mesma pessoa: possível em pequenos projetos (para Brooks, de 3 a 6 programadores). Mas uma combinação arriscada em projetos maiores. Brooks justifica: “Pensadores são raros; executores são raros; pensadores-executores são raríssimos”.
    • O Produtor é o chefe e o Arquiteto o seu braço direito: a dificuldade aqui, segundo Brooks, é o estabelecimento da autoridade do Produtor em questões técnicas. Ele diz que o entrosamento entre o Produtor e o Arquiteto é fundamental. E que o primeiro deve respeitar muito o valor do arquiteto.
    • O Arquiteto é o chefe e o Produtor o seu braço direito: segundo Brooks, este seria o arranjo ideal para equipes pequenas, enquanto o anterior (Produtor é o chefe) funcionaria melhor em projetos maiores.

    É impossível evitar o paralelo das sugestões de Fred Brooks com aquelas apresentadas por Jeff Sutherland (depois de Takeuchi e Nonaka ) em seu método chamado Scrum.

    Jeff Sutherland, ao contrário de Brooks, não deixa dúvida sobre quem ‘fala mais alto’ em um projeto. O Arquiteto, que no Scrum é chamado de Product Owner, tem a palavra final. Enquanto o Coordenador (Produtor), ou Scrum Master, trata de eliminar riscos e obstáculos que estejam impedindo o time de obter sua melhor performance. São, respectivamente, o “Navegador” e o “Piloto” em uma equipe de rally, uma analogia criada pelo próprio Sutherland.
    Este desenho faz lembrar também uma colocação de Tom DeMarco em um de seus principais trabalhos, “Peopleware”:

    “A função do gerente não é fazer as pessoas trabalharem e sim tornar possível que elas trabalhem.“

    Antes de encerrar o tema uma observação: Fred Brooks, assim como Scott Berkun, trabalhou na indústria, desenvolvendo ‘produtos’. Falta em seus ‘job descriptions’ do Arquiteto e do Produtor (Coordenador) a preocupação com um Cliente. Parece óbvio que o chefe, seja ele o Arquiteto ou o Coodenador, seja a principal interface da equipe do projeto com o cliente. Eu prefiro deixar que o Coordenador seja sempre o canal de contato principal com o cliente, independente de ter ou não a ‘palavra final’ no projeto. As questões técnicas e funcionais, na maior parte das vezes, deveriam ser solucionadas (ou direcionadas) pelo Analista de Negócio, apresentado no sub-capítulo anterior.

    A Outra função da Organização

    Quando falamos em Organização, Estrutura, a primeira imagem que aparece é a de um organograma. Nos preocupamos, quase que exclusivamente, em saber quem é que manda no pedaço e quem deve (ter o juízo de) obedecer. Fred Brooks diz que precisamos aprender a desenhar estruturas e processos que incentivem, e não que inibam a criatividade e a iniciativa. E lembra: “a Criatividade vem dos indivíduos e não das estruturas e processos”.

    Scott Berkun segue linha parecida dizendo que os “projetos dependem muito da habilidade do time em fazer uso do conhecimento de seus membros, de compartilhar idéias e trabalhar em sincronicidade, ao invés de seguir restritivas linhas de autoridade, uma rigorosa disciplina e uma compulsão a seguir ordens sem nenhum tipo de questionamento”.

    Esse embate é muitíssimo bem documentado por Domenico de Masi no livro “Criatividade e Grupos Criativos”. Domenico afirma que atravessamos uma fase caracterizada por um Cultural Gap, um fenômeno que “constrangeu os atuais knowledge workers, os trabalhadores do conhecimento, a se organizarem segundo os velhos princípios industriais”.

    Que seja só uma fase. Mas ainda não há muitos indícios de que esteja para terminar. Por exemplo, o termo “fábrica de software” é de uma infelicidade incrível. Um oxímoro, no meu ponto de vista. Por outro lado temos a consolidação de produtos como Linux, Apache, Eclipse e Firefox, que são criados em ambientes onde parece imperar o caos. Deve haver um meio termo, não?

    ===

    Na próxima semana, “Castelos de Areia…”, sobre engenharia de requisitos, integridade conceitual, especificações e trabalho criativo. (Título com bula, atendendo a pedidos, hehe).

    1. Takeuchi e Nonaka, “The New New Product Development Game”, Harvard Business Review (Jan-Fev/1986).
    2. Tom DeMarco e Timothy Lister, “Peopleware – Productive Projects and Teams”, 2ª edição – Dorset House (1999, 1987).
    3. Domenico de Masi, “Criatividade e Grupos Criativos”, Editora Sextante (2003).