PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Livro

  • Rendiconti :: O Projeto

    Vamos conversar agora sobre como o negócio Rendiconti será desenvolvido. Pode não ter ficado claro no post anterior, mas a iniciativa é composta por duas grandes partes: a fábrica-gráfica, de tijolo, cimento e tecnologia; e o site.

    A primeira já recebeu, há cerca de 2 meses, a maior parte do investimento necessário. Uma grande impressora laser já está em operação; o processo de produção já foi delineado; a pequena grande equipe já foi treinada. Esta parte foi antecipada exatamente para que a adequação à nova tecnologia aconteça bem antes da demanda que será gerada pelo site. Com um calculado efeito colateral bastante positivo: a gráfica (que, como eu já disse, pertence aos manos Cacá e Guz) ganhou outra fonte de receitas. Agora ela presta um tipo de serviço (popularmente conhecido como “gráfica rápida”) que é inviável quando se tem apenas impressoras ‘off-set’.

    Merece destaque o maior (e, de certa forma desejado) risco: se a demanda proveniente do site for muito grande teremos problema de escala – e o prometido prazo médio de 3 dias úteis para a entrega das obras pode ser comprometido. Como a aquisição de mais impressoras está, por enquanto, fora de cogitação, foram traçadas duas alternativas:

    1. Outras gráficas da cidade (Vga!) possuem tecnologia similar. Receberão a demanda excedente;
    2. Se a demanda for grande também para elas, de duas uma: ou é boa o suficiente para justificar mais investimentos (impressoras), ou forçará uma parceria com uma gráfica de maior porte (no interior de São Paulo).

    Só quando esta parte mais crítica e de certa forma mais cara foi resolvida é que teve início a 2ª parte do projeto: o site.

    Há uns 4 anos sou um satisfeito freguês da Locaweb. Não tinha nenhum motivo para buscar outro hospedeiro. Meu servidor contratado, claro, é Linux. E isso gerou o primeiro requisito não-funcional do projeto: a arquitetura tecnológica do site se baseará em PHP e MySQL. Esta opção já cria um necessário filtro de eventuais fornecedores. Vale dizer também que o PHP me deixou muito bem impressionado desde o dia em que converti o finito para o WordPress. PHP 5, Ajax, MySQL, talvez algumas ‘frescurinhas’ em Flash – estes são os principais componentes da arquitetura tecnológica do site.

    Também não tive nenhuma dificuldade para definir o arquiteto-desenvolvedor: Hailton Ferraz, de Lençóis Paulista e estudante da UNESP de Bauru. Ágil, enviou uma proposta objetiva e bastante clara. Profissional e rápido como poucas grandes e médias empresas sabem ser. Mas eu tinha outras motivações para ‘cravar’ este projeto no meio do interior e no meio acadêmico:

    • Como um Quixote bêbado espero dar uma contribuição, por menor que seja, para que o pessoal pare de “ir a São Paulo pra trabalhar”. O fluxo ganhou um “U-Turn” (tks! Stone, que passou no Intercine de ontem). Estamos no século XXI. Temos Internet. Temos banda larga (capenga mas temos). Ninguém precisa estar em Sampa para desenvolver projetos. Que nossas viagens para lá sejam só para passeio e encontros (profissionais ou não). Ou, no pior cenário, para breves estadias. E só!
    • O projeto do site é um excelente experimento. Por isso o 2º requisito não-funcional é fundamental: o projeto será 100% “open source”. Espero que ele seja estudado. Torço para que ele sirva como exemplo em diversas aulas. E vou utilizá-lo para trocar conhecimentos com a turma de Analistas e Desenvolvedores que convivem comigo no nosso grupo de discussão e no recém-nascido Fórum FAN.br. Imagine que exercício legal: estarei fazendo o papel do freguês! Vamos praticar: a modelagem do negócio e seus processos; o desenvolvimento e gerenciamento de requisitos; gerenciamento de projetos; um processo de desenvolvimento enxuto e ágil, iterativo e incremental; etc etc. Tudo de forma aberta: como eu já escrevi aqui, todos os artefatos gerados serão públicos – e liberados para uso.

    Ô FUQ! (Frequently Unasked Questions):

    • Bah! Então o projeto vai demorar pra caramba, não?
      Não! Há um negócio aqui, não se esqueça. Por mais que pareça uma brincadeira, o negócio é sério. Aliás, parecer uma “brincadeira” – no sentido de ser divertido – é uma qualidade que todo projeto de software deveria ter. Desde que seja uma diversão séria!
      Então o projeto tem um prazo sim: que flutua* entre setembro e outubro de 2008.
      * Flutua tanto quanto o custo: a forma de aquisição (que ainda tratarei naquela esquecida série “Trabalhando em Casa”) é formalmente conhecida como “Aquisição Progressiva”. Há um chute inicial (como em 100% dos projetos), mas valores e prazos serão ajustados na medida em que o projeto evoluir.
      * Tento provar assim que aquele “mantra” que diz que só o escopo pode flutuar é pura “forçação de barra”.
    • E qual é o escopo do projeto?
      Mostrei no post de ontem que ele tem duas partes principais: o cadastramento de obras e a venda delas. Pouca coisa além disso já foi debatida. Como ocorre em praticamente 100% dos projetos de software, é impossível ter uma visão de todo o escopo em seus momentos iniciais. Neste momento (que em alguns processos é conhecido como “Incepção”) buscamos uma visão que chamo de “2km de extensão e 2cm de profundidade”. É parte dos exercícios.
    • Tanto barulho para um projeto de um cara só?
      O Hailton é o contratado, arquiteto e principal responsável pela execução do projeto. Mas quem disse que é um projeto de um cara só? Claro que estou pessoalmente envolvido em sua execução, não apenas como o (chato) freguês. Mas já tivemos a colaboração de uma dezena de “voluntários”. Talvez tenhamos contribuições de dezenas, centenas de pessoas. Quem pode dizer? O projeto é aberto e livre. Se for um bom imã, atrairá esforços até de onde menos esperamos. É esperar e ver no que dá.
    • E como se gerencia um projeto assim?
      Honestamente? Não sei. É meu primeiro projeto de verdade que nasce “open source” – livre. Ferramentas para a estruturação e gerenciamento do conhecimento (requisitos!) adquirido serão necessárias. Mas essa parte até que é facilmente resolvida com os repositórios conhecidos. O maior problema estará no processo de gerenciamento. Taí uma bela oportunidade de aprendizado.
    • Qual processo de desenvolvimento será utilizado?
      Enxuto e ágil, Iterativo e Incremental. Talvez a gente crie um nome para ele, mas isso não importa. Surrupiaremos as boas idéias (e práticas) de propostas como OpenUP, FDD e até XP. Mas não seguiremos nenhum processo de forma cega, como algumas pessoas (ainda) acreditam que seja possível. Neste momento só há um princípio (ou requisito) escrito em pedra: o processo deve facilitar o aprendizado, em todos os sentidos. Só!
    • Os modelos, tanto do negócio quanto do projeto, são um tanto românticos, não?
      Como dizia uma bela psicóloga que um dia me deu um tratamento (informal), “não há altruísmo”. É claro que eu espero ganhar muito com o projeto, em todos os sentidos. Há a perspectiva de um belo retorno financeiro. Há a publicidade “orgânica” – tanto do negócio propriamente dito quanto do meu livro que, claro, representa a nova ponta-de-lança do meu “lucro” (daquele papo “Troco – Lucro – Truco”). E, obviamente, espero aprender muito – particularmente com o projeto. Ou seja, não sou assim tão “bonzinho e generoso”.
    • E se der tudo errado?
      Tudo é muita coisa. No pior cenário todos os envolvidos terão aprendido alguma coisa. O projeto é relativamente simples e “barato” (não estou apostando minha vida nele – meu negócio principal (meu lucro), o finito, seguirá com ou sem o Rendiconti). Mas, de certa forma, “aposto” meu nome aqui. Falhas no projeto ou no negócio, com certeza, gerarão uma péssima impressão. Mas… como dizia o saudoso e vitorioso Vicente Matheus: “quem sai na chuva é pra se queimar”.

  • Rendiconti :: O Negócio

    Artigo publicado originalmente no Graffiti. Talvez lhe interesse conhecer toda a (pré) história que o antecedeu. Então, segue o índice:

    Trato aqui de um novo negócio. Antes, porém, uma necessária explicação sobre o nome. Rendiconti é um termo italiano que significa “Prestação de Contas”. O utilizo com frequência neste espaço para prestar contas de todos os eventos abertos que realizo. A sacada do Guccia na escolha deste nome para sua revista é genial. Surrupio-a sem medo de ficar com a cara vermelha de vergonha.

    Aprendemos com os outros, com experiências de outras pessoas. Em aulas, livros, bate-papos presenciais ou virtuais – não importa. Todo aprendizado é um evento social, por solitário que seja. “Social”? É, eu quis dizer que tudo que aprendemos vem de outras pessoas.

    Quando invertemos este fluxo, tentando ensinar outras pessoas, de certa forma estamos fazendo uma “Prestação de Contas”. É uma retribuição – mas sempre seremos avaliados pelo que agregamos àquele conhecimento adquirido. Por isso o periódico do Círculo Matemático de Palermo se chamava Rendiconti. O conceito é genial. A provocação, impagável!

    Por isso não pensei duas vezes ao selecionar o nome desta nova empreitada. Aliás, depois de tantas idéias jogadas aqui, está aqui a primeira que pego para realizar. O título original daquele livro do Domenico de Masi, “Criatividade e Grupos Criativos“, é “La Fantasia e la Concretezza“. Sabe-se lá porque a Sextante, seguindo o (mau) exemplo das distribuidoras de filmes, não fez uma tradução literal do nome. Não importa. Para De Masi, o criativo não apenas fantasia. Ele também deve ser capaz de concretizar suas idéias. Antecipando a confissão de que não estou sendo nada criativo, topei o desafio.

    Para quem pulou o prólogo, explico que tudo começou porque vou publicar meu primeiro livro. Ia fazê-lo da forma tradicional (que tem mais de 500 anos!). Imprimiria uns 1000 exemplares e ficaria aguardando que generosas almas os levassem para casa (ou escritório). Modelo pra lá de ultrapassado: Muita grana parada. Considerando que incentivo a cópia e a distribuição de versões digitais do texto; considerando que as centenas de pessoas que participaram de meus eventos já garantiram (sem custos adicionais) sua cópia digital; e considerando que hoje em dia se lê muito pouco, qual demanda eu teria? Quanto tempo levaria para esvaziar aquela pilha de 1000 volumes?

    Mas a questão não é só essa, meramente comercial (ou financeira, como queiram. Aliás, já disse por aqui, não espero ganhar $ nenhum com a venda do livro). A principal questão é outra: trato o livro como se trata um software: ele é vivo – tem versões. A última versão pública é a 0.6. Em breve soltarei capítulos de uma versão que estou chamando de “release candidate”. A versão comercial será, obviamente, a ‘um ponto zero’. Mas morrerá ali? Duvido…

    Agora mesmo trabalho com 3 ferramentas (técnicas) novas, de modelagem, que espero incorporar ao trabalho. Outras surgirão, motivando a publicação das versões 1.1, 1.5, 2.0 e assim por diante. Com tal processo de desenvolvimento, a impressão de grandes volumes (a única que se justifica financeiramente em gráficas tradicionais) seria um tiro no pé. Motivações mais do que suficientes para a criação de um novo negócio. Nasce assim a Rendiconti!

    O Modelo do Negócio

    Como eu disse, não é nada original. Surrupia sem dó nem medo partes dos modelos da lulu.com e do SafariU, do grupo O’Reilly. Trata-se de uma gráfica e editora do século XXI: só gasta papel e tinta quando o cliente confirma a aquisição de um livro (ou artigo, apostila, revista, etc). Existem dois processos principais:

    1. O autor publica uma obra.
      Ele faz o upload de um arquivo com toda a obra. E tem a possibilidade de configurar diversos parâmetros como: preço, material, tipo de capa, opção de venda da versão digital, extensões da obra etc.
      Quando aprovada pelo editor, a obra passa a integrar o portfólio da loja Rendiconti. Aparecerá na ‘vitrine’, de acordo com sua classificação.
      Restrições: i) a Rendiconti trabalhará exclusivamente com livros técnicos das áreas de TI (Tecnologia da Informação) e Negócios; ii) a editora se reserva o direito de recusar obras que não atendam o padrão mínimo de qualidade esperado ou que fujam de seus temas principais (veja considerações abaixo).
    2. Um cliente adquire uma obra
      A loja Rendiconti opera como uma loja virtual comum. Há o inevitável “carrinho de compras” e coisa e tal. Claro, brigaremos para criar metáforas mais interessantes e originais. Mas não há muito o que inventar aqui.
      Ops, há sim! O cliente pode personalizar a obra adquirida: capa, tipo de papel, dedicatória, logo da empresa… sempre respeitando as restrições configuradas pelo autor.
      A “contribuição” do SafariU: o cliente pode montar um livro ou apostila inédito, selecionando capítulos das diversas obras disponíveis na loja. Poderá inclusive fazer o upload de algum material seu para ser incorporado. Invenção pequena é bobagem. Personalização tímida é enganação!
      Outra novidade, o processo: a obra só será impressa após a confirmação do pedido. Toda a operação estará baseada em Varginha, Minas. Mas o prazo médio de entrega dos pedidos girará em torno de 3 dias úteis – prazo equivalente ao das lojas tradicionais.

    Imaginem, então, as diversas possibilidades (cenários):

    • Um professor pode elaborar um material, mixá-lo ao conteúdo disponível na Rendiconti e gerar apostilas muito especiais para seus alunos;
    • Uma empresa pode elaborar um material de treinamento e terceirizar sua confecção (e até a revisão!). Desta forma, pode configurar para que sua obra não seja pública – ou seja, não aparecerá na vitrine da Rendiconti;
    • Claro, meu livro e seus 12 (?) capítulos estarão ali, exclusivamente ali na loja Rendiconti. Nas mais diversas versões: quer só a parte de modelagem de negócios, ou só o módulo de engenharia de requisitos? Tudo bem. Quer comprar apenas um capítulo? Só a versão digital? Só a apostila? Definitivamente: o cliente manda. E a gente tratará de entregar exatamente o que ele precisa.

    É óbvio, espero que vários autores vejam na Rendiconti uma oportunidade de prestar contas, de dar à luz as suas obras. Aliás, neste início de empreitada, é este o meu maior desafio: atrair autores. Claro, respeitarei tudo o que caracterizou a Rendiconti original. Não importa se você é professor ou estudante, doutor ou iniciante. Não importa se você está em Quixeramobim, na Mutuca ou na Lagoa dos Patos. E não importa se você é desenvolvedor, coordenador de projetos, administrador, consultor, professor, estagiário ou estudante. Saca a cauda longa? Então, há mercado para tudo – há espaço para todo mundo.

    Considerações semi-finais

    • “Não temes que lhe roubem o modelo de negócio?”
      Tsc… que papo mais anos 2000, pré-bolha. Conheces o dito “ladrão que rouba ladrão”? Então, não disse que surrupiei e remixei idéias de duas empresas estadunidenses? Então pq eu deveria reclamar se alguém buscar inspiração aqui?
    • Aliás, espero que busquem bem mais. Como mostrarei com mais detalhes no próximo post, este é um projeto 100% aberto. Todo o código e demais artefatos gerados (inclusive o modelo do negócio) serão disponibilizados com licenças Creative Commons e GPLv3.
    • Portanto, quem quiser copiar, poderá obter bem mais que uma simples idéia. Quer montar sua própria loja? Que tal uma especializada em livros “Boa Vida Boa” (culinária, viagens, esportes etc)? Que tal uma só com obras de cultura inútil? Que tal uma só para escritores renegados? Como eu disse (depois do Chris Anderson), há espaço e mercado para tudo. Já sugeriram até que eu escrevesse um livro só para contar essa história. Pode? Rss… até o próximo!

  • EPBE: O Negócio e sua Estrutura

    Finalmente a continuação da série que começou em “EPBE: Introdução“. Neste artigo vou apresentar duas das quatro visões propostas: a Visão do Negócio e a Visão da Estrutura. Lembrete importante, não mencionado no capítulo anterior: as 4 visões propostas pela EPBE (Processos e Comportamento completam a lista) são básicas, mas não mandatórias nem fixas. Podemos suprimir alguma, dependendo das necessidades e do projeto. Também podemos criar novas visões, como “Papéis e Objetivos das Pessoas”, “Visão dos Efeitos Econômicos”, etc. A EPBE, assim como seu alicerce, a UML, é extensível. Por exemplo, veja neste artigo do IEEE (pago), até onde levaram a EPBE.

    Como colocado anteriormente, o objetivo desta série é apresentar a EPBE e seus elementos básicos. Quem sabe, num futuro próximo, possamos explorar outros usos e extensões. Hoje vou mostrar um pequeno exemplo. Vou incorporar dois elementos que não existem na EPBE original: Balanced Scorecard e Mapas estratégicos. Eles nos ajudarão a documentar a estratégia da empresa.

    .:.

    A Visão do Negócio guia a modelagem das outras três visões. Isso porque é nela que aprendemos e registramos quais são os objetivos do negócio. Portanto, a construção da visão do negócio é o ponto de partida do processo de modelagem do negócio. Das 4 visões básicas propostas pela EPBE, esta é a única que não se consolida na forma de diagramas. Na realidade, em alguns casos, criamos apenas um grande modelo conceitual que destaca os principais elementos (ou conceitos) do negócio. Veja o exemplo (rabiscado) abaixo:

    Por favor, não espere que o desenho acima derive para um diagrama de classes ou algo do tipo. O AN lança mão dessa ferramenta para facilitar sua compreensão do negócio. E, ao consolidá-la, pode utilizar o mesmo desenho para explicar o negócio para outros interessados. Só (isso tudo).

    Crucial no desenvolvimento da visão do negócio é a compreensão de seus objetivos. Na proposta original da EPBE, essa parte principal é registrada na forma de texto. Os principais pontos a destacar são: Missão, Objetivos, Forças, Fraquezas, Oportunidades, Ameaças (obs: as 4 últimas são conhecidas também como matriz SWOT), Fatores Críticos, Estratégias, Competências Principais, Perfis, Unidades de Negócio e Processos-chave. Ao detalhar as estratégias pode ser necessário que também destaquemos: Clientes, Concorrentes, Ambiente, Lucratividade, Potencial de Crescimento e a Percepção que o mercado tem da empresa. O nível de detalhamento deste documento vai depender bastante das necessidades da empresa ou do projeto em questão. Quanto mais estratégico for o projeto, maior a necessidade de um estudo mais minucioso das variáveis listadas acima.

    A EPBE não cita, mas eu gosto de completar o estudo acima com duas informações adicionais: a Proposição de Valor da empresa e o seu Modelo Operacional. Dois artigos publicados anteriormente neste espaço apresentam com um pouco mais de detalhes os dois estudos:

    Parto do princípio de que 90% dos novos projetos abertos pelas organizações têm um cunho estratégico. É raro vermos hoje em dia projetos que lidem com processos de negócio secundários, como folha de pagamento, contabilidade e afins (que, se não estão terceirizados, já foram devidamente informatizados). Sendo assim, a grande maioria dos projetos está vinculada à alguma iniciativa estratégica. Aqui nasce o alinhamento *estratégico* de TI com o negócio. Compreender e se comprometer com a estratégia do negócio é fundamental para o sucesso do projeto.

    Por isso sugiro a incorporação de duas ferramentas que têm se mostrado bastante eficazes na elaboração, execução e acompanhamento das estratégias de negócio: o Balanced Scorecard e seu co-irmão, o Mapa Estratégico . Se a empresa não for usuária destas ferramentas, ou seja, se eles não estiverem disponíveis em sua forma tradicional e “bonitinha”…


    … ainda assim, o AN pode desenvolvê-las:


    Aliás, mesmo que eles existam em sua forma tradicional, é recomendável a elaboração do diagrama acima, em UML. Ao utilizar uma ferramenta CASE, e não o meu tosco rabisco, o AN ganha a facilidade de vincular objetivos, iniciativas e indicadores aos processos (como veremos no próximo capítulo desta série).

    Minha sugestão não deve ser vista como uma substituição àquela da EPBE original, mas como um complemento. Se ela substitui alguma coisa, é o diagrama “Objetivos/Problemas” proposto por Eriksson e Penker. Trata-se de uma extensão, como prometi no início do artigo. Cabe relembrar outra coisa: a Visão do Negócio servirá como *guia* para o desenvolvimento das outras 3 visões. Veremos agora mais uma delas.

    A Visão da Estrutura do Negócio

    Quando falamos de Estrutura do Negócio estamos falando de todos os seus Recursos. No capítulo anterior vimos que recurso é tudo o que a empresa utiliza, consome ou produz. Portanto, com esta visão, detalhamos como a empresa organiza seus produtos e serviços, suas informações e também a si mesma, na forma de unidades de negócios, departamentos, cargos etc. Normalmente utilizamos apenas uma variação do tradicional diagrama de classes da UML para representar todos os tipos de recursos. As informações, por exemplo, são representadas em um grande modelo conceitual que lembra muito um tradicional modelo E-R. Aliás, para ser franco, é o mesmo cara.

    Já o organograma da empresa pode ser traduzido num diagrama mais ou menos assim:


    Estamos falando de documentos que normalmente o AN já encontrará em uma empresa. Portanto, a única justificativa para a sua (re)construção em UML é a facilidade que uma ferramenta CASE pode proporcionar quando o AN entrar na parte “dura” da modelagem de negócios: seus Processos. Assunto do próximo capítulo. Inté.

    .:.

    Bibliografia:

    1. Business Modeling with UML – Business Patterns at Work
      Hans-Erik Eriksson e Magnus Penker. Wiley (2000).
    2. Para quem quiser conhecer o básico sobre Balanced Scorecards e Mapas Estratégicos, recomendo dois títulos:
      a) Medindo o Desempenho Empresarial – Harvard Business Review. Campus (2000).
      b) Mapas Estratégicos – Robert Kaplan e David Norton. Campus (2004).

    .:.

  • Sobre o Livro (e uma Oferta)

    Quando decidi escrever meu primeiro livro, não tinha a menor idéia de como seria o processo. Escrever artigos, mesmo aqueles longos, é uma coisa. Um livro é totalmente diferente. Seth Godin e Scott Berkun, em seus blogs, costumam contar um pouco sobre seu processo. Ariano Suassuna, Chico Buarque e Luis Fernando Veríssimo me assustaram um tanto com seus depoimentos sobre o trampo. Mas, no final das contas, cada um tem seu processo, suas manias e traumas. Resolvi desenvolver meu próprio processo (e manias). Espero não colecionar muitos traumas. Mas sei que alguns serão inevitáveis.

    Começando do começo, fixei alguns princípios:

    • Liberdade total, tanto no conteúdo quanto no formato de distribuição, precificação etc. O livro sairá com uma variação da licença Creative Commons, algo que uma editora tradicional dificilmente entenderia. Principalmente porque haverá uma versão digital (eBook), mais fácil de ser copiada.
    • O livro será um meio, não o fim. Será a principal peça de marketing do finito por um tempo. Ou seja, não tenho a ilusão de fazer grana com o livro. Se ele se pagar, já será um belo feito.
    • Peça de marketing não pode significar um livro “marketeiro” (no mau sentido). O conteúdo do livro deve ser prático, útil, rico e bem fundamentado.
    • O livro é um esforço “solo”. Mas deve ser amplo em experiências e pontos de vista. A bibliografia consultada até agora, mais de uma centena de livros, não é suficiente. A área (Análise de Negócios) é relativamente nova. O risco de lançar um livro “míope” (ou “caolho”) é muito grande.
    • Apesar de conhecer a tendência, o livro não será do tipo “como passar na prova”. Se ele ajudar na obtenção de certificações, particularmente a CBAP do IIBA, tudo bem. Mas este, definitivamente, não é um objetivo do texto.

    Na seqüência desenhei a extensão do livro, uma visão de “alto nível”. Para se ter uma idéia, ainda não sei se ele terá 9 ou 10 capítulos. A versão com 8 capítulos já é conhecida por umas 120 pessoas (114 participantes dos workshops e 6 “convidados”). No plano original, ainda seguido, espero que ele alcance um mínimo de 400 pessoas. Quanto mais heterogêneo for esse grupo, melhor (veja oferta abaixo).

    Por isso os workshops que estou realizando com a Tempo Real Eventos são tão importantes. Não pelo contato de 1 dia, mas pelas conversas que acontecem depois. Por isso montei um grupo de discussão “fechado”. Ali posso receber críticas e sugestões. Ali nós trocamos idéias sobre o conteúdo, práticas, processos…

    Pois é, adotei um processo Iterativo & Incremental para o desenvolvimento do livro. Sendo assim, posso dizer que nos encontramos na fase de construção, na 7ª iteração. O produto, o texto, já está na versão 0.6. Chegamos em uma fase em que as iterações precisam ser mais curtas. Mas o cronograma segue rigorosamente em dia.

    O trabalho de escrita, com todas as revisões, se encerra em dezembro. Já divulguei até a data oficial de lançamento: 27/mar/2008 (quinta-feira) Um dia eu explico a data e o codinome do rebento, “É o Negócio, Beócio“.

    .:.

    Do mesmo conteúdo gerei uma palestra (1h30), o workshop (7hs) e um curso (80hs, dividido em dois módulos de 40hs: Modelagem de Negócios e Engenharia de Requisitos).

    Segue aqui uma oferta para escolas, universidades e entidades sem fins lucrativos (de Sampa ou Varginha): quem quiser levar a palestra ou workshop para suas organizações (em outubro ou novembro), não terá custo nenhum. Demais localidades podem ser incluídas, dependendo da distância e das despesas de deslocamento. Todos os participantes receberão uma cópia (digital) do livro (que ainda é uma apostila) e outros artefatos. Se interessou? Então, fale comigo.

    .:.

  • Novo Berkun

    No próximo dia 15/mai será lançado o novo livro de Scott Berkun, “The Myths of Innovation“. É só o segundo. O primeiro foi “The Art of Project Management“, best seller e um dos melhores do gênero. Há pouco mais de um ano publiquei um “resumão” dele, comparando-o com o clássico “The Mythical Man-Month“.

    Berkun escreve de forma aberta. Há tempos ele escreveu em seu blog qual seria o tema do livro e passou a documentar a evolução. Usou o blog como fonte de pesquisas e para validação de seus achados. O novo livro é pequeno (192 págs) e o tema um tanto espinhoso. O melhor livro sobre inovação e criatividade que conheço é “Criatividade e Grupos Criativos”, de Domenico de Masi. Pelas breves descrições do novo Berkun já disponíveis, dá para perceber algumas coincidências:

    • Why all innovation is a collaborative process
    • How innovation depends on persuasion
    • Why problems are more important than solutions
    • How the good innovation is the enemy of the great
    • Why the biggest challenge is knowing when it’s good enough

    Sairá um “De De Masi a Berkun”? hehe.. Não creio. Não só porque o título seria horrível, mas porque tenho outras prioridades. Logo elas aparecerão por aqui. Mas, com certeza, o novo Berkun deve dar o empurrão definitivo para que eu encerre aquela série sobre o “Gerenciamento do Trabalho Criativo“.

    Mas fica a tentação: De Masi, em “Criativade”, conta toda a história da humanidade e pára em meados do século XX. Berkun conta a história das inovações olhando tudo o que veio depois, TI, software etc. Deve ser um belo complemento.

    .

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

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

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

  • Como montar Times e influenciar Projetos

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

    A experiência prática de Fred Brooks, como citado anteriormente, foi com projetos mastodônticos: 1000 pessoas envolvidas ou mais. Mas ele lembra que desde aquela época os ‘gerentes de programação’ preferiam “pequenos e ‘agudos’ times formados por pessoas de ‘primeira classe’”. Brooks cita um estudo (de Sackman, Erikson e Grant) que mostra que um programador de ‘primeira classe’, que recebia US$20.000/ano, podia ser até 10 vezes mais produtivo que um programador de US$10.000/ano. Mas um pequeno grupo de ‘estrelas’ seria capaz de desenvolver um OS/360? Talvez em 10 ou 25 anos, segundo cálculos do autor. Por outro lado Brooks lembra que times grandes, orientados para a execução de um trabalho na base da ‘força bruta’, são “lentos, caros, ineficientes, e produzem sistemas que não possuem ‘integridade arquitetônica’. OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE, etc. A lista é longa”. E “o dilema é cruel”, escreve Brooks. Haveria solução?

    A sugestão de Brooks, baseada em uma proposta de Harlan Mills , dá título para o terceiro capítulo do seu livro, “O Time Cirúrgico”. Segundo ele, o time ideal é formado por:

    • Programador Chefe (Cirurgião)
    • Co-Piloto
    • Administrador
    • Editor
    • Secretárias (duas)
    • Bibliotecário
    • Almoxarife
    • Testador
    • Advogado (da Linguagem)

    Reparem bem. Nós temos praticamente 9 pessoas trabalhando para o programador! Dando-lhe “todo suporte que fará aumentar sua eficácia e produtividade”. Lembram-se que o Brooks também sugeria que alocássemos apenas 1/6 de nosso cronograma para tarefas de codificação? Outro mundo, não é mesmo? Pode e deve ser factível em um time cirúrgico de verdade mas aplica-se a equipes montadas para o desenvolvimento de sistemas?

    O ‘cirurgião’ seria responsável pela execução de todas as tarefas principais daquela parte do projeto: sua especificação, design, codificação, testes e documentação. Não difere muito de alguns job descriptions e anúncios de vagas que ainda vemos por aí. Seria um “analista-programador” que, segundo Brooks, deveria ter 10 anos de experiência.

    O mundo da programação mudou muito desde os tempos do COBOL e da PL/I. A complexidade e abrangência de nossas linguagens e arquiteturas de aplicações aumentaram ‘para os lados e para baixo’. E é cada vez mais comum que cada uma das tarefas listadas acima seja atribuída a um especialista. Uma divisão que é nítida em ‘fábricas de software’, por exemplo. Em caminho oposto, alguns advogados de métodos ágeis enaltecem a importância de um time formado por ‘generalistas’.

    A analogia com equipes médicas reaparece em um artigo de Peter Drucker publicado pela Harvard Business Review em 1988, “O Advento da Nova Organização” . Segundo Drucker, “informação é dado investido de relevância e propósito. Por conseguinte, a conversão de dados em informação requer conhecimento. E conhecimento, por definição, é especializado. (Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender).”

    Apesar de ser simpático aos chamados métodos ágeis, não acredito na possibilidade ou eficácia de um time composto por ‘generalistas’. Prefiro apostar em uma formação que valorize o perfil e a experiência de cada um de seus membros. No diagrama abaixo apresento um exemplo de um time desenhado para desenvolver uma aplicação web (ou ‘cliente/servidor n camadas’, como queiram):

    O arquiteto é o novo ‘cirurgião’. É o dono e principal responsável por aquele projeto ou módulo. Mas só coloca ‘a mão na massa’, codificando, para transferir conhecimentos. Ocupa-se com a concepção e manutenção da integridade arquitetônica da solução. Ele é diretamente apoiado por cinco especialistas:

    • Analista de Negócios (biz): cuida da coleta e organização dos requisitos, e apóia seu desenvolvimento, fazendo a ponte entre os usuários e a equipe de desenvolvimento;
    • Desenvolvedor de Interfaces (front): é especialista em usabilidade e ‘manda bem’ em conceitos de arquitetura de informações. Hoje deve ‘brincar’ com AJAX (Javascript), Flash, HTML, CSS, ASP, JSP, JSF e afins.
    • Desenvolvedor de Serviços (srv): domina orientação a objetos, componentização e, mais recentemente, serviços. É um programador clássico que, como tal, não leva o menor jeito com as ‘frescuras da camada de apresentação’.
    • Arquiteto de Informações (data): uma versão remoçada dos DBA’s (administradores de bancos de dados). Domina o desenho e desenvolvimento de bases tradicionais, transacionais, mas também sabe quando lançar mão de sistemas gerenciadores de conteúdo e bases analíticas.
    • Nosso antigo inimigo (infraestrutura): são os responsáveis por nossos servidores, redes, firewalls e outros brinquedinhos. Tê-los como parte da equipe de projeto desde os primeiros dias é uma prática que, com certeza, minimiza aquele ‘jogo de empurra’ que costuma acontecer um pouco antes ou um pouco depois do delivery da solução.

    Mas… e o coordenador? No próximo sub-capítulo falo especificamente sobre ele e sua convivência com o arquiteto.

    Agora, seguindo com o time cirúrgico proposto por Fred Brooks. O co-piloto que ele sugere é o ‘alter ego’ do cirurgião, capaz de executar qualquer tarefa atribuída à este. A única diferença é que o co-piloto seria menos experiente. Mas, ainda assim, funcionaria como um backup do cirurgião, inclusive representando-o em reuniões com outras equipes. Porém sua principal função é avaliar e discutir as idéias do programador-chefe. Lembra uma das práticas sugeridas pelo método conhecido como eXtreme Programming (XisPê – para os íntimos), a Pair Programming. A prática é polêmica e eu não disponho de dados que confirmem ou não as promessas de produtividade. Quero crer que a qualidade do código gerado realmente seja superior. Mas tenho algumas considerações que, por questão de tempo e espaço, tratarei em outra oportunidade.

    O ‘Administrador’ sugerido por Brooks é um tipo de Coordenador do Projeto. Apesar do cirurgião ter a palavra final em todas as questões, é o administrador que cuida do dia-a-dia da gestão financeira, de pessoal, suprimentos etc. Mais sobre o assunto no sub-capítulo seguinte.

    O ‘Editor’ é o responsável pela documentação. O cirurgião, segundo a proposta de Brooks, gera os documentos principais, tanto técnicos quanto aqueles para os usuários finais. Mas seria o editor o responsável pela compilação final, anexação de referências, bibliografia etc. É um luxo. Porém, ainda hoje brigamos para obter bons documentos de bons programadores, inutilmente.

    O ‘Bibliotecário’ – ‘escriturário’, ou program clerk, como sugerido por Brooks, não faz muito sentido nos dias de hoje. Mas parecia ser crucial nos tempos dos cartões perfurados e das intermináveis listas impressas em formulários contínuos. No entanto eu acredito que toda organização que esteja buscando o reuso de seus ativos de software, ou implantando uma SOA (Arquitetura Orientada a Serviços), demandará a presença de um bibliotecário, um especialista que em outro artigo eu chamei de GBA (Gestor da Biblioteca de Ativos).

    Se prestarmos atenção na complexidade dos atuais ambientes integrados de desenvolvimento (IDE’s – Integrated Development Environment), com seus frameworks, testes automáticos, integração com ferramentas de modelagem etc, veremos que pode fazer sentido o papel do ‘Almoxarife’, ou toolsmith, na nomenclatura original utilizada por Brooks. Um profissional especializado nas ferramentas e na sua adequação para cada tipo de projeto e função. Em equipes grandes ou em ‘fábricas’, parece ser uma função de grande utilidade.

    O ‘Testador’ é o nosso “Engenheiro de Testes”, uma função que aos poucos vai se tornando mais comum. Pena que muitos ainda o confundam com um ‘programador que não deu certo’. Teste é coisa séria, tanto que Brooks, como mostramos na 1ª parte desta série, dedicaria 50% do esforço de um projeto exclusivamente para ele.

    Por fim Brooks sugere a alocação de um ‘Advogado da Linguagem’. Creio que nossos espertíssimos e modernos IDE’s, nossos ‘testadores’ e, lógico, o arquiteto, eliminam a necessidade de um ‘language lawyer’. Advogado não, né?

    continua…

    ===

    1. Mills, H., “Chief Programmer teams, principles, and procedures”, IBM Federal Systems Division Report FSC 71-5108, Gaithersburg, Md., 1971.
    2. Artigo republicado em “Gestão do Conhecimento” (Harvard Business Review on Knowledge Management), Editora Campus, 2001.

  • Questão de Confiança

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

    Berkun diz que o problema com nossos projetos não está nos cronogramas mas sim na forma como eles são elaborados e usados. O coordenador deve confiar nas estimativas apresentadas pelos programadores e demais membros do time. Se cada estimativa apresentada for bem justificada, não há porque desconfiar delas. Uma questão de validação: quão prováveis são os prazos fixados? “Se nenhuma probabilidade é oferecida e nenhuma pré-condição é colocada, então a realização do cronograma pode até ser possível, mas não é provável”.

    Que base de comparação, quais referências nós possuímos para avaliar corretamente as estimativas apresentadas? Tanto Brooks (em 75!) quanto Berkun insistem: só o domínio do nosso histórico, tanto de equipes quanto dos indivíduos, permitirá um julgamento justo. Qual a nossa produtividade, nossa ‘performance histórica’? Qual o índice de incidência de bugs? Existem estimativas para módulos/projetos semelhantes? Como elas foram elaboradas e quais fatores elas consideraram? Não há mágica!

    Por outro lado, os programadores devem confiar no plano, no cronograma apresentado. Como? Entendendo a lógica que o criou.

    O tema me faz lembrar duas provocações daquelas, feitas por Watts Humphrey:

    “Por que profissionais competentes concordam com cronogramas quando não têm a menor idéia sobre como irão cumpri-los?”

    “Por que executivos racionais aceitam tais cronogramas quando os engenheiros não oferecem a menor evidência de que poderão respeitá-los?”

    Berkun fecha o tema apresentando uma série de pequenas dicas muito úteis:

    • A duração de uma iteração deve ser coerente com a volatilidade do projeto. Quanto mais volátil, menor** deve ser a duração da iteração;
    • Devemos ser otimistas na elaboração do Documento de Visão (que será apresentado posteriormente) e pessimistas no cronograma*;
    • Devemos apostar no Design;
    • E planejar pontos em que as alterações de escopo serão permitidas;
    • Tornar pública a ‘filosofia’ do Plano – Cronograma;
    • Considerar a experiência da equipe no tipo de projeto que estamos tratando;
    • Assim como seu entrosamento;
    • E antecipar os riscos. Sempre! (o ‘Sempre’ foi meu).

    Só então, estabelecido um compromisso entre todos aqueles que se envolverão diretamente no desenvolvimento do projeto, é que o cronograma deveria ser Negociado com o cliente. Choque de realidade: muitas equipes são estruturadas após o ‘fechamento do negócio’. É triste, mas temo que não seja uma exceção.

    Não é difícil entender o ‘outro lado’. Normalmente, quando um projeto sai da área de negócios para aquisição, via departamento de TI, ele já está atrasado. Já é ‘para ontem’. Normal…

    … O problema começa quando a aquisição é fechada, o cronograma é apresentado desprovido “da menor evidência de que poderá ser cumprido”.

    Aos poucos estamos aprendendo que a Aquisição Progressiva é uma alternativa muito superior para contratações de projetos de software. Em linhas gerais: um projeto é fatiado em fases (normalmente todos já são); e as partes negociam apenas a fase imediatamente seguinte, aquela que apresenta o menor grau de incerteza. As partes começam com um grande número e um cronograma ‘genérico’, e concordam em refiná-lo no decorrer do projeto. O contratante pode optar por abrir uma nova concorrência a cada iteração/fase, mostrando independência e, principalmente, muita maturidade (em seus processos de desenvolvimento e aquisição de sistemas).

    Cronogramas: Um Meta-Modelo

    No texto original de “The Mythical Man-Month” Fred Brooks apresenta um ‘meta-modelo’ que deveria guiar a construção de todos os cronogramas. As regrinhas:

    • 1/3 – Planejamento
    • 1/6 – Codificação
    • 1/4 – Testes individuais
    • 1/4 – Testes de integração

    No capítulo 19 da edição especial do livro, “… after 20 years”, Brooks admite que seu modelo é muito waterfall (cascata). Pode ser, mas também pode ser adaptado para modelos de ciclo de vida mais modernos, iterativos (cíclicos) e incrementais.

    Mas… que luxo! Gastar 33% do tempo do projeto só em em planejamento!! E 50% do tempo do projeto em testes!?!

    Scott Berkun não deixa por menos e nos apresenta a “regra dos terços”:

    • 30% – Design
    • 30% – Programação
    • 30% – Testes

    Provavelmente gastamos os 10% que restam tentando justificar o cronograma, não é mesmo? Brincadeirinha…

    A simplicidade e objetividade das duas sugestões acima assustam um pouco. Mas, pense um pouco: Elas são válidas! Ambos começam concordando que devemos consumir cerca de 30% de todo o tempo do projeto apenas em seu planejamento e arquitetura. Isso não significa que, em um projeto de 9 meses, os três primeiros serão consumidos exclusivamente em atividades de planejamento e design. Em um processo de desenvolvimento mais moderno (apresentados na última parte da série), você planeja cada iteração. Mas se trata de um número justo. Eu diria ‘generoso’, se considerarmos diversos de nossos projetos.

    Berkun é também um desenvolvedor. Brooks nunca foi. Talvez isso explique o fato de Berkun dar o dobro de tempo para as atividades de codificação. Um pouco mais de 15%, como sugerido por Brooks, realmente é muito pouco. Mesmo com todos os frameworks e geradores de código ‘da vida’.

    Por fim temos as atividades tão ignoradas em tantos cronogramas: os famigerados Testes. Brooks pesa a mão e destina 50% de um cronograma exclusivamente para eles. Berkun se contenta com 30%. (Por favor, tentem esquecer por alguns instantes que ele trabalhou na MS, no projeto Windows, ok?).

    Régua, Esquadro e Bom Senso

    São os três elementos que devem existir entre o relógio-cronograma e a bola de cristal que apóia nossas estimativas. A Régua é nosso histórico de métricas, nossos índices de produtividade e coisas do tipo. Concordo que a máxima “não se gerencia o que não se mede” não se aplica totalmente em nossa área. Mas ignorar nossos números, definitivamente, não ajudará em nada.

    O Esquadro deve representar nossas ferramentas de apoio e ajuste. Se estamos em uma fase inicial do projeto, talvez os Use-Case Points sejam úteis. Já temos informações suficientes para municiar estimativas baseadas em Análise por Pontos de Função? Lancemos mão dela! Desde que não ignoremos o que a Régua nos ensinou.

    Por fim o mais importante: o tal Bom Senso. Na boca de muitos e em tão poucos projetos! O cliente não forneceu informações suficientes para uma boa estimativa? Então seja sincero e diga para ele que a estimativa apresentada é de ‘baixa qualidade’. Você suspeita que os requisitos são muito voláteis? Por que não sugerir um contrato de Aquisição Progressiva? Você não tem uma mínima equipe apoiando-o na elaboração das estimativas? Cobre o chefe. Ou contrate a mãe Diná, sei lá…

    —

    ** (update, 15/mar): estava aqui o erro apontado pelo Jonas Fagundes nos comentários. Tks!

    * Tem outra ‘regrinha’ que brinca com o equilíbrio “Otimismo X Pessimismo” que gosto bastante: tenha um Arquiteto pessimista e um Engenheiro otimista. Contradiz a regrinha do Berkun, mas costuma funcionar bem. Mas isso é assunto para o próximo post.

    Semana que vem: “Como montar equipes e influenciar projetos“.

    ps: Não, não sou fã do pai de todos os livros de auto-ajuda, “Como fazer amigos e influenciar pessoas”. Nada contra. Até já ganhei umas três cópias de alguns ‘amigos’. Mas, sei lá, entende? É uma questão de confiança.