finito

Tag: Engenharia de Requisitos

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

    .:.

  • O Giro em Falso das Rodas Reinventadas

    Há quem ache que a síndrome NIH (Not Invented Here) é uma exclusividade dos desenvolvedores. Não é. Parece que toda a nossa área adora reinventar rodas, eixos e padrões. O tempo todo.

    Foto de Tom@HK.

    Eu poderia citar n exemplos, como a mal explicada briga da MS com o padrão UML; as metodologias que adoram dar novos nomes e símbolos para coisas que já existem; “oceanos azuis” e outras metáforas criativas para diferenciação; sistemas de help-desk que viram, da noite para o dia, soluções de CRM… Pois é, não é só uma questão de reinvenção. As segundas intenções (as verdadeiras motivações para a “reinvenção”) são ainda mais perigosas.

    Mas a motivação para este post veio de outro lugar. Do BABoK (Business Analysis Body of Knowledge), que é uma das minhas referências para o livro e o workshop/curso para formação de Analistas de Negócios.

    O BABoK é novo. A versão que estou utilizando é apresentada como um “draft 1.6”, de julho do ano passado. Como eu disse em outro post, o BABoK se concentra quase que exclusivamente na Engenharia de Requisitos. Mas trata a disciplina como se fosse algo totalmente novo. Parece que o tema não foi estudado anteriormente e compilado em propostas como o CMMI, SWEBoK etc etc. O padrão da SEI, por exemplo, só aparece como “CMM” em algumas poucas referências. No corpo do “corpo” ele é sumariamente ignorado.

    Caramba, o CMMI tem duas áreas-chave que tratam especificamente de requisitos: REQM (Gerenciamento de Requisitos) e RD (Desenvolvimento de Requisitos). A vinculação do BABoK com ele deveria aparecer, no mínimo, como uma matriz que mostrasse como as práticas ali recomendadas auxiliam na realização dos objetivos do CMMI.

    Mas os “agilistas” não têm motivo para comemorar. Suas práticas e métodos também não existem no BABoK. Aparecem pequenas referências e alertas, dizendo, por exemplo, que “em projetos ágeis e iterativos os requisitos não são baselined (sorry) ao mesmo tempo”. Não há quase nada além disso.

    Acho que nem preciso dizer que “gestão do conhecimento” e “aprendizagem organizacional” também não foram consideradas na elaboração do BABoK. Pois é, infelizmente, a versão atual é só uma compilação de práticas ‘levemente acopladas’. Apresentadas de forma linear, estruturadas de acordo com este diagrama. Como as práticas são relativamente bem documentas (propósito, descrição, técnicas, processo, stakeholders e deliverables – toda prática ou tarefa é apresentada com esta estrutura), o BABoK deve se tornar apenas um tipo de “guia de referência rápida”. Um excelente template para elaboração de provas de múltipla escolha. E talvez, numa versão 3.0, apresente uma disciplina nova chamada “integração” ou algo do tipo.

    Talvez fosse só esse mesmo o seu objetivo. Mas acho que todo mundo espera mais de algo que se apresenta como um “Corpo de Conhecimentos da Análise de Negócios”. A primeira coisa que eu sempre espero é que ele não ignore os conhecimentos existentes. Rodas reinventadas giram em falso.

    .:.

  • O Analista de Negócios e o tal BABoK

    Faz pouco tempo que descobri o BABoK (Business Analysis Body of Knowledge). Quem cuida dele é o IIBA (International Institute of Business Analysis). A descoberta aconteceu por acidente, no meio das minhas pesquisas. Usando o Google, não consegui achar nenhuma referência em língua portuguesa. Estranhei. Afinal, a versão atual (1.6) está disponível para download desde 12/jul do ano passado. A versão 2.0 está programada para este trimestre. Mas, como escrevi no meu material, “o analista de negócios não existe. Particularmente aqui no Brasil”. Normal. Quantos gerentes de projetos existiam há uns 10 anos? E quem conhecia o PMI?

    O IIBA segue os passos do PMI. Ou seja, lança um ‘guia para o corpo de conhecimentos’ e, na cola, uma certificação. Tenho minhas restrições ao formato, mas elas ficam para outra hora. O lado bom é que a iniciativa pode ajudar a divulgar e, de certa forma, consolidar a profissão. Em tempos de altas ondas (SOA e BPM), passa da hora de percebermos que o Analista de Negócios desempenha funções cruciais.
    .

    .:.


    Mas o BABoK me assustou um pouco e decepcionou um tanto. Ainda não vi as alterações previstas para a versão 2.0, mas a versão 1.6 cobre, na minha opinião, apenas 50% do trabalho de um AN. Dos seus 8 capítulos, 5 cobrem exclusivamente as atividades de planejamento, desenvolvimento e gerenciamento de requisitos. O gráfico abaixo ilustra as áreas de conhecimento cobertas pelo BABoK:

    “Enterprise Analysis”, segundo capítulo do BABoK, é descrita como “uma coleção de atividades pré-projeto que servem para capturar uma visão futura do negócio, formando assim uma base a a elicitação de requisitos e para o desenho da solução “.

    Como já comentei aqui, e talvez seja uma falha minha, mas não consigo dissociar a Modelagem de Negócios da Engenharia de Requisitos. Lógico, são duas disciplinas diferentes. Mas elas compartilham “momentos”, independente do modelo de processo utilizado. E o BABoK não fala nada sobre Modelagem de Negócios. Se ela não é uma responsabilidade do AN, então é de quem?

    Quero crer que, com a demanda gerada pelas ‘ondas’ BPM e SOA, o BABoK passe a contemplar atividades para modelagem de negócios e de processos de negócios em suas futuras versões. Melhor seria se a incorporação fosse motivada pela percepção de que o trabalho do AN não se restringe à coleta, análise e documentação de requisitos.

    .:.

    Como mostra o conteúdo programático do workshop promovido pela Tempo Real Eventos, a primeira metade do evento tratará exclusivamente da modelagem do negócio e seus processos. Apresentarei algumas práticas sugeridas pelo BABoK na segunda parte do evento.

    .:.

  • Para que serve o Analista de Negócios?

    A pergunta acima, colocada num fórum de discussão há pouco tempo, foi o último empurrão que eu esperava. Volta e meia ouvimos que problemas com a compreensão do negócio e com requisitos respondem por cerca de 80% das causas das falhas em projetos. Com uma freqüência ainda maior, somos comunicados de que uma das maiores prioridades das áreas de TI nos últimos tempos é o alinhamento com o negócio. Mas, por incrível que pareça, um dos profissionais mais importantes no atendimento dessas duas demandas é pouco conhecido. Afinal, quem é o Analista de Negócios (AN)? Qual a sua formação? Quais as suas habilidades? E, mais importante, quais as suas responsabilidades em uma organização de TI e em projetos para desenvolvimento ou implantação de sistemas?

    Há muito tempo o tema me persegue. Em 98, logo que cheguei em Sampa, entrei numa briga surreal para conseguir justificar, contratar e treinar 2 Analistas de Negócios. Minha primeira palestra aberta, realizada nos idos de 2002, foi sobre um dos dois principais conjuntos de disciplinas que devem ser dominados por um AN: a Engenharia de Requisitos. Nos últimos tempos, com a confirmação das propostas SOA e BPM, a importância e a necessidade de Analistas de Negócios cresceram ainda mais. Ainda assim, suspeito que pouco se sabe sobre eles e suas funções.

    Por isso comecei a compilar minhas experiências e meus achados com o intuito de lançar um workshop e um treinamento. Eles apareceram no meu ‘cardápio’ deste ano. O primeiro workshop aberto, chamado “Formação para Analistas de Negócios“, será realizado pela Tempo Real Eventos. Acontecerá no próximo dia 19/junho (uma terça-feira), em Sampa. Dura o dia todo e tem 50 vagas.

    Update: a data mudou. O workshop será no dia 20/junho (quarta-feira).

    .:.

    Há tempos um pessoal mais próximo me cobra: “por que você não escreve um livro?”. Minha resposta era sempre a mesma: “não tenho assunto”. Caramba, nesta semana completo 3 anos de blogs. Só no Graffiti são mais de 1400 posts. Mas eu realmente nunca tinha achado uma “lacuna”. Não iria “chover no molhado” com mais um título sobre gerenciamento de projetos, apesar de achar que existem boas oportunidades e áreas pouco cobertas (TOC, OpenUP, Scrum), particularmente em língua portuguesa. Também não tenho como escrever sobre reuso e gerenciamento de ativos de software. Careço de mais e melhores experiências.

    Mas quando vi que a minha apostila para o curso “Formando Analistas de Negócios” estava ficando grande demais – o curso tem 80 horas – a ficha caiu. Caramba, está aí meu primeiro livro. Era tão óbvio, estava tão ‘colado no nariz’, que quase perco a oportunidade.

    Utilizarei um ‘draft’ do livro como apostila, tanto para o workshop quanto para os treinamentos. Será uma forma legal de validar os escritos – um tipo de “versão beta”. Alguns exercícios e exemplos que pintarem nos eventos devem ser incorporados ao texto final. E, claro, utilizarei este blog para breves pesquisas, sugestões, críticas e também para documentar o andamento do processo.

    Conteúdo programático e outras informações sobre o workshop já estão no site da Tempo Real Eventos. Se quiserem conversar comigo sobre o evento ou o livro, fiquem à vontade.

    .:.

  • Transformando Etiquetas em uma Base de Conhecimentos

    Extensão do capítulo “Etiquetando Ativos de Software“, penúltimo capítulo publicado até agora na série “Gerenciando Ativos de Software“.

    Neste ponto eu começaria a escrever sobre os processos necessários para a administração de ativos de software e para o reuso. O ponto de partida e um dos fatores mais importantes e críticos tanto para o reuso quanto na implementação de uma SOA é a Engenharia de Requisitos — ou, colocando em outro padrão, o Desenvolvimento e o Gerenciamento de Requisitos. Para explicar a importância desta disciplina no contexto da série, basta lembrar uma frase que citei em um dos primeiros capítulos: “Oportunidades de reuso são como bugs: quanto antes elas forem encontradas, melhor” .

    As similaridades e as diferenças entre aplicações são encontradas em dois lugares principais: nos requisitos e na arquitetura. O primeiro delimita o problema. A segunda aponta uma forma de solução. Foi aqui que esbarrei numa questão que acabou ‘forçando’ este post: afinal, como coletar requisitos com o objetivo de detectar oportunidades de reuso?

    A busca pela resposta acabou me levando de volta para uma antiga briga*: sem uma base de conhecimentos bem estruturada, esse levantamento é uma tarefa hercúlea, cara e nada ágil. Se boa parte das ferramentas para administração de requisitos ainda não achou uma boa solução para a rastreabilidade*, o que esperar então da forma como elas tratarão essa “nova” demanda?

    Porque não se trata apenas de recuperar os requisitos. Devemos ter condições de analisar todo o histórico de construção – observar todas as derivações (modelos, código etc) e conhecer as decisões tomadas. Conhecer todo o ciclo de vida de um ativo pode ser um fator determinante para a sua reutilização.

    As etiquetas RAS, apresentadas anteriormente, suprem uma parte dessas necessidades. Mas tanto as suas informações quanto a sua forma de persistência não atenderiam plenamente a demanda pela busca e comparação de requisitos.

    Uma deficiência do padrão, apontada anteriormente, é o fato dele não contemplar o histórico de (re)uso do ativo. Se considerarmos então tudo o que precisamos saber sobre os requisitos, definitivamente o padrão RAS não é suficiente. Sua forma de armazenamento (arquivos XML em um sistema de arquivos tradicional) também não facilita as tarefas de busca. Precisamos de uma base de conhecimentos bem estruturada. E sua persistência em um sistema gerenciador de bancos de dados parece ser a melhor alternativa.

    O padrão RAS é extensível. E ele já recebe informações sobre requisitos na entidade/classe “Artefato”. O que eu sugiro no diagrama acima é uma extensão do padrão, de forma que ele possa contemplar informações mais específicas sobre os requisitos e sobre o negócio. Utilizei três fontes para traçar o diagrama conceitual: a base que descrevi no artigo supra-citado*, o “Requirements Knowledge Model” de Suzanne e James Robertson , e o meta-modelo básico de conceitos de modelagem de negócios proposto por Hans-Erik Eriksson e Magnus Penker .

    Todos os requisitos são associados aos casos de uso que, por sua vez, são vinculados à processos de negócio. A caracterização e descrição dos processos é apoiada por quatro elementos básicos: seus Objetivos, Recursos, Eventos e Regras. Informações básicas sobre o negócio podem facilitar a busca e a comparação de requisitos.

    Os requisitos também são associados aos elementos que formam a solução. A vinculação direta é com os casos de uso, segundo o padrão RAS, também são cadastrados como “Artefatos”. Desta forma é possível rastrear todas as derivações que ocorreram durante o desenvolvimento de determinada solução.

    Na parte inferior do diagrama eu apenas sinalizo a possibilidade de classificar e detalhar melhor os requisitos.

    É importante salientar que nós não reusamos UM requisito. Não buscamos isso. O que se reutiliza é um conjunto (cluster) de requisitos. Todos os descritores e entidades sugeridas acima existem para possibilitar a formação um conjunto. Por exemplo: podemos selecionar todos os requisitos de um determinado processo de negócio; todos os requisitos funcionais que referenciem determinado recurso; os requisitos não-funcionais de determinado produto / serviço; e assim por diante.

    .:.

    Não é minha intenção aprofundar muito nas questões colocadas neste post. Tanto que ele nem está no ‘padrão de escrita’ da série. Posteriormente, na versão editada desta série e em outros artigos, falarei mais sobre a construção de uma Base de Conhecimentos para organizações que desenvolvem software.

    * Obs.: Na realidade, preciso reescrever e corrigir este artigo. É de 2003, e até hoje tá ali no canto, falando de “requerimentos”.

    .:.

    Referências:

    1. Practical Software Reuse
      Michel Ezran, Maurizio Moricio e Colin Tully
      Springer (2002).
    2. Requirements-Led Project Management
      Suzanne Robertson e James Robertson
      Addison-Wesley (2005).
    3. Business Modeling with UML – Business Patterns at Work
      Hans-Erik Eriksson e Magnus Penker
      Wiley (2000).

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