De Brooks a Berkun

Um estudo informal dos livros The Mythical Man-Month e The Art of Project Management, e uma homenagem aos seus autores, Fred Brooks e Scott Berkun. Paulo Vasconcellos
Abril/2006

Prlogo
Em 2005 comemorou-se 30 anos do lanamento da primeira edio de "The Mythical Man-Month", de Frederick P. Brooks Jr. O livro pode ser considerado o primeiro clssico das reas de Engenharia de Software e Gerenciamento de Projetos. Fred Brooks trabalhou por 8 anos na IBM, entre 1956 e 1964. Seu ltimo ano foi dedicado ao desenvolvimento do OS/360, um empreendimento que envolveu mais de 5 mil homens/ano. Surge ento a provocao que o levaria ao livro, uma 'pergunta bsica' de Thomas Watson (CEO da IBM):

Por que programao to difcil de ser gerenciada?

Trs dcadas de avanos tecnolgicos e de consolidao das cincias Engenharia de Software e Gerenciamento de Projetos no foram suficientes para tornar o texto obsoleto. Muito pelo contrrio: at hoje o livro considerado uma referncia obrigatria. Em 2004, quando questionado sobre a razo da longevidade de sua obra-prima Fred Brooks respondeu: "Eles falam que o livro a Bblia da Engenharia de Software... por isso que todo mundo o l mas ningum o usa!". No ano em que comemorou seu trigsimo aniversrio, "The Mythical Man-Month" ganhou um tipo de upgrade, de complemento. Trata-se de "The Art of Project Management", de Scott Berkun. No s uma coincidncia de temas, afinal existem milhares de ttulos sobre Gesto de Projetos e Engenharia de Software. Mas vrios outros aspectos aproximam as duas obras. Scott Berkun trabalhou por dez anos na Microsoft, em projetos como Windows, MSN e Internet Explorer. Ou seja, Berkun reviveu experincias parecidas com aquelas de Brooks em uma corporao de porte e relevncia quase idnticas.

2/60  2/60 

No por acaso que os dois livros possuem linguagem e estrutura muito parecidos. Podem ser classificados como histrias de guerras. Ambos so muito fceis de ler e seguem uma ordem prpria, em detrimento de padres, nomenclaturas e sequncias que caracterizam 9 em 10 ttulos sobre gerenciamento de projetos lanados nos ltimos tempos. Este artigo foi concebido originalmente para comemorar os 30 anos de "The Mythical Man-Month". Compar-lo ao recm lanado "The Art of Project Management" s uma maneira de tornar a homenagem e, por que no dizer, as provocaes, um pouco mais ricas. Por incrvel que parea, nem "The Mythical Man-Month" nem "The Art of Project Management" mereceram uma edio em portugus do Brasil. Um lapso que ainda pode ser corrigido. E deveria. Como so best sellers, mesmo por aqui, razo comercial no h. Como Gesto de Projetos est na moda, resta-nos torcer para que, no meio daquele tanto de livro lanado para ajudar a gente a passar na prova, apaream mais ttulos como os de Brooks e Berkun. Este artigo no deve ser visto, de forma alguma, como uma alternativa aos textos originais. Ele deve servir como um incentivo para a leitura de ambos. Ou releitura, por que no? Em 1995, foi publicada uma edio de "The Mysthical Man-Month", comemorando os 20 anos da obra. Ela traz uma srie de artigos e captulos complementares. Mas o texto original, como era de se esperar, foi mantido. Que a experincia seja agradvel e til.

3/60  3/60 

ndice
Prlogo............................................................................ 2 Entre o Relgio e a Bola de Cristal .......................................... 5 Cronogramas so s um Tipo de Previso ......................... 8 Questo de Confiana ................................................ 10 Cronogramas: Um Meta-Modelo .................................... 13 Rgua, Esquadro e Bom Senso ...................................... 15 Como montar Times e influenciar Projetos .............................. 16 Os Dois Donos do Projeto ............................................ 22 A Outra funo da Organizao .................................... 25 Castelos de Areia... ........................................................... 26 Vai Entender o que o Cliente Quer ................................ 32 ... E a inevitabilidade das Mars ........................................... 40 Planejar ou no Planejar? uma questo?....................... 44 A Receita e o Bolo de Fub .................................................. 47 Receitas, Metodologias, Processos................................. 50 Eplogo ........................................................................... 53 Servio ................................................................... 55 Outras Obras Citadas ................................................. 56 Crditos e Consideraes Finais.................................... 57

"Seres humanos, que so quase nicos em sua capacidade de aprender com as experincias dos outros, tambm se caracterizam por sua resistncia em faz-lo." Douglas Adams

4/60  4/60 

Entre o Relgio e a Bola de Cristal

No segundo captulo de "The Mythical Man-Month", homnimo, Fred Brooks mostra um fac-smile do cardpio do Restaurant Antoine, de New Orleans. Destaca um Avis au Public, que aparece logo no cabealho do menu:

"Good cooking takes time. If you era made to wait, it is to serve you better, and to please you.
Brooks apresenta cinco razes para nossos constantes e interminveis atrasos. O primeiro o incurvel otimismo de programadores e afins. Ele diz que nossas tcnicas de estimativas so pobres e refletem uma situao irreal: de que tudo vai dar certo. Esse mesmo otimismo nos faria negligenciar, particularmente, a fase de testes de um projeto. O segundo motivo seria a confuso entre "Esforo" e "Progresso". Tal confuso nasceria da falsa crena de que Homens e Meses (Horas) so intercambiveis. Brooks refora que s conseguimos trocar alguns 'meses' por um monte de 'gente' em um conjunto de atividades que no exijam nenhum tipo de interao entre as pessoas. Acho que nem em panha de caf existe tal isolamento...

5/60  5/60 

A terceira razo relacionada por Brooks para os atrasos em nossos projetos chata e provocativa: ns no somos sinceros como o chef do Antoine. A facilidade com que damos 'chutes' e apresentamos cronogramas sem um mnimo de embasamento realmente assustadora. Pior: apresentando-os como 'srios'. E a responsabilidade tanto de quem pede quanto de quem d. J vi empresa muito grande solicitar uma proposta para um projeto de milhes apresentando um documento de 7 (sete!) pginas e fazendo uma reuniozinha com os possveis contratados. Tamanha negligncia em qualquer outra rea deve ser caso de polcia. Na nossa parece 'normal'. A forma como acompanhamos e monitoramos a evoluo de nossos cronogramas seria a quarta razo. A impresso que grande parte dos projetos nos transmite que, assim que eles ganham ritmo, perde-se o controle.

"Adicionar pessoas a um projeto de software atrasado s adiar a sua entrega." - A Lei de Brooks
Por ltimo Brooks cita sua lei como outra grande razo para nossos atrasos. Segundo ele, adicionar pessoas a um projeto atrasado como "tentar apagar um incndio com gasolina". Cada novo membro pode significar uma nova cadeia de interaes e restries. A quantidade de meses de um projeto dependeria de suas restries sequenciais. O nmero mximo de pessoas dependeria do nmero de sub-tarefas independentes. Podemos elaborar um cronograma mais 'demorado' utilizando menos pessoas. Mas no podemos encurtar seu prazo natural adicionando mos!

6/60  6/60 

Recentemente Scott Berkun publicou uma srie de 'excees' Lei de Brooks. Alertando que no queria, de maneira alguma, sugerir o abandono da lei. O prprio Brooks j reconheceu que sua lei "ultrajantemente super-simplificada". Abaixo as excees apontadas por Berkun:
D Depende da pessoa: lgico! O acrscimo de uma ou mais pessoas mais experientes que aquelas da

equipe atual pode, eu disse Pode, gerar um efeito positivo no projeto.

D Alguns times podem assumir mudanas mais facilmente: acho que depende inclusive de um

entrosamento prvio dos novos integrantes com os antigos. Um entrosamento proveniente de projetos anteriores. Mas depende principalmente das outras aes do coordenador (ltimo tpico abaixo).
D H coisas piores que estar atrasado: com certeza, como entregar algo totalmente diferente daquilo

que o cliente espera. Berkun lembra bem: "a nica coisa que a lei fala que o projeto atrasar 'mais' com a adio de mais pessoas". Mas tal acrscimo pode ser benfico ou crucial para o resultado final do projeto.
D H diferentes maneiras de adicionar pessoas a um projeto: mas Berkun lembra bem que nossa

tradio jogar gente l para ver no que que d. Se bem pensada, a adio (ou troca) de pessoas em um time pode ser benfica.
D Depende da razo do atraso do projeto, para comeo de conversa: claro! Se o(s) motivo(s) no

for(em) bem identificado(s), de que adianta jogar mais pessoas na frigideira?

D A adio de pessoas pode ser combinada com outras aes do coordenador: pode no, deve. No

mnimo aes que otimizem (minimizem) o nmero de interaes e facilitem a rpida absoro do projeto pelo(s) novo(s) integrante(s).

7/60  7/60 

Cronogramas so s um Tipo de Previso

Mas h quem os trate como se fossem documentos sagrados. Para Scott Berkun os cronogramas "no so remdio para um projeto (design) ou prticas de engenharia ruins e tambm no podem proteger um projeto de uma liderana fraca, objetivos obscuros e comunicao pobre". Independentemente do tempo gasto e do capricho com que um cronograma foi elaborado, "no final das contas eles so apenas uma lista de palavras e nmeros". Uma lista que, segundo Berkun, deve ter trs objetivos bem claros:
D Descrever quais tarefas devem ser executadas, quando e quais produtos sero gerados; D Funcionar como um integrador da equipe, indicando dependncias e amplificando os compromissos

mtuos; e
D Fornecer para o time uma ferramenta que possibilite o acompanhamento da evoluo do projeto e

que permita estrutur-lo em etapas mais gerenciveis.

E no que tem cliente que, inconscientemente (quero acreditar), prefere ver um cronograma atualizado do que software rodando? Querendo ou no, os cronogramas viraram o 'grande' documento de um projeto de software. Responsabilidade demais para algo que deveria ser s mais uma ferramenta. Pior: para algo que deveria evoluir junto com o projeto.

"A elaborao do melhor cronograma, usando as mais capacitadas pessoas e as melhores ferramentas, tambm ser uma tentativa de prever o futuro. Algo que nossa espcie raramente faz bem." - Scott Berkun

8/60  8/60 

 impossvel gerar um cronograma com um mnimo de acuracidade no momento inicial de um projeto. Berkun afirma e milhares de projetos confirmam esta 'lei'. Mas continuamos insistindo. Berkun gerou o grfico ao lado a partir de "Software Engineering Economics" [1], de Barry Boehm. Nos momentos iniciais de um projeto nosso 'chute' pode ter uma variao de 400%. H quem arrisque 4 dgitos... Berkun afirma que a volatilidade dos requisitos, dentre outros fatores, pode gerar estimativas de baixa qualidade. E que no h nada de errado com elas desde que sejam apresentadas como tal: Estimativas de Baixa Qualidade. E sugere a adoo de Nveis de Confiabilidade para nossas estimativas:
D 40% - s um chute; D 70% - uma boa estimativa; D 90% - estudamos e detalhamos (quase) tudo.

Uma boa estimativa dependeria principalmente de dois fatores: bons requisitos e um bom design (temas que sero tratados posteriormente).E Berkun ainda pede: confie em seus programadores como voc confiaria em um neuro-cirurgio. Se este falar que aquela operao no crebro demorar 12 horas, voc tem coragem de pedir para que ele reduza para, digamos, 4 horas? Voc seria o louco o suficiente?

9/60  9/60 

Questo de Confiana
Berkun diz que o problema com nossos projetos no est nos cronogramas mas sim na forma como eles so elaborados e usados. O coordenador deve confiar nas estimativas apresentadas pelos programadores e demais membros do time. Se cada estimativa apresentada for bem justificada, no h porque desconfiar delas. Uma questo de validao: quo provveis so os prazos fixados? "Se nenhuma probabilidade oferecida e nenhuma pr-condio colocada, ento a realizao do cronograma pode at ser possvel, mas no provvel". Que base de comparao, quais referncias ns possumos para avaliar corretamente as estimativas apresentadas? Tanto Brooks (em 75!) quanto Berkun insistem: s o domnio do nosso histrico, tanto de equipes quanto dos indivduos, permitir um julgamento justo. Qual a nossa produtividade, nossa 'performance histrica'? Qual o ndice de incidncia de bugs? Existem estimativas para mdulos/projetos semelhantes? Como elas foram elaboradas e quais fatores elas consideraram? No h mgica! Por outro lado, os programadores devem confiar no plano, no cronograma apresentado. Como? Entendendo a lgica que o criou. O tema me faz lembrar duas provocaes daquelas, feitas por Watts Humphrey:

10/60  10/60 

"Por que profissionais competentes concordam com cronogramas quando no tm a menor idia sobre como iro cumpri-los?" "Por que executivos racionais aceitam tais cronogramas quando os engenheiros no oferecem a menor evidncia de que podero respeit-los?"
Berkun fecha o tema apresentando uma srie de pequenas dicas muito teis:
D A durao de uma iterao deve ser coerente com a volatilidade do projeto. Quanto mais voltil,

menor deve ser a durao da iterao;

D Devemos ser otimistas na elaborao do Documento de Viso (que ser apresentado posteriormente)

e pessimistas no cronograma;
D Devemos apostar no Design; D E planejar pontos em que as alteraes de escopo sero permitidas; D Tornar pblica a 'filosofia' do Plano Cronograma; D Considerar a experincia da equipe no tipo de projeto que estamos tratando; D Assim como seu entrosamento; D E antecipar os riscos. Sempre! (o Sempre foi meu).

S ento, estabelecido um compromisso entre todos aqueles que se envolvero diretamente no desenvolvimento do projeto, que o cronograma deveria ser negociado com o cliente. Choque de realidade: muitas equipes so estruturadas aps o fechamento do negcio. triste, mas temo que no seja uma exceo.

11/60  11/60 

No difcil entender o 'outro lado'. Normalmente, quando um projeto sai da rea de negcios para aquisio, via departamento de TI, ele j est atrasado. J 'para ontem'. Normal... ... O problema comea quando a aquisio fechada, o cronograma apresentado desprovido "da menor evidncia de que poder ser cumprido". Aos poucos estamos aprendendo que a Aquisio Progressiva uma alternativa muito superior para contrataes de projetos de software. Em linhas gerais: um projeto fatiado em fases (normalmente todos j so); e as partes negociam apenas a fase imediatamente seguinte, aquela que apresenta o menor grau de incerteza. As partes comeam com um grande nmero e um cronograma 'genrico', e concordam em refinlo no decorrer do projeto. O contratante pode optar por abrir uma nova concorrncia a cada iterao/fase, mostrando independncia e, principalmente, muita maturidade (em seus processos de desenvolvimento e aquisio de sistemas).

12/60  12/60 

Cronogramas: Um Meta-Modelo
No texto original de "The Mythical Man-Month" Fred Brooks apresenta um meta-modelo que deveria guiar a construo de todos os cronogramas. As regrinhas:
D 1/3 Planejamento D 1/6 Codificao D 1/4 Testes individuais D 1/4 Testes de integrao

No captulo 19 da edio especial do livro, "... after 20 years", Brooks admite que seu modelo muito waterfall (cascata). , mas tambm pode ser adaptado para modelos de ciclo de vida mais modernos, iterativos (cclicos) 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 no deixa por menos e nos apresenta a "regra dos teros":
D 30% - Design D 30% - Programao D 30% - Testes

Provavelmente gastamos os 10% que restam tentando justificar o cronograma... Brincadeirinha... A simplicidade e objetividade das duas sugestes acima assustam. Mas, pense um pouco: Elas so vlidas!

13/60  13/60 

Ambos comeam concordando que devemos consumir cerca de 30% de todo o tempo do projeto apenas em seu planejamento e arquitetura. Isso no significa que, em um projeto de 9 meses, os trs primeiros sero consumidos exclusivamente em atividades de planejamento e design. Em um processo de desenvolvimento mais moderno voc planeja cada iterao. Mas se trata de um nmero justo. Eu diria generoso, se considerarmos diversos de nossos projetos. Berkun tambm um desenvolvedor. Brooks nunca foi. Talvez isso explique o fato de Berkun dar o dobro de tempo para as atividades de codificao. Um pouco mais de 15%, como sugerido por Brooks, realmente muito pouco. Mesmo com todos os frameworks e geradores de cdigo 'da vida'. Por fim temos as atividades to ignoradas em tantos cronogramas: os famigerados Testes. Brooks pesa a mo 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?).

14/60  14/60 

Rgua, Esquadro e Bom Senso

So os trs elementos que devem existir entre o relgio-cronograma e a bola de cristal que apia nossas estimativas. A Rgua nosso histrico de mtricas, nossos ndices de produtividade e coisas do tipo. Concordo que a mxima "no se gerencia o que no se mede" no se aplica totalmente em nossa rea. Mas ignorar nossos nmeros, definitivamente, no 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 informaes suficientes para municiar estimativas baseadas em Anlise por Pontos de Funo? Lancemos mo dela! Desde que no ignoremos o que a Rgua nos ensinou. Por fim o mais importante: o tal Bom Senso. Na boca de muitos e em to poucos projetos! O cliente no forneceu informaes suficientes para uma boa estimativa? Ento seja sincero e diga para ele que a estimativa apresentada de 'baixa qualidade'. Voc suspeita que os requisitos so muito volteis? Por que no sugerir um contrato de Aquisio Progressiva? Voc no tem uma mnima equipe apoiando-o na elaborao das estimativas? Cobre o chefe. Ou contrate a me Dinah, sei l...

15/60  15/60 

Como montar Times e influenciar Projetos

A experincia prtica de Fred Brooks, como citado anteriormente, foi com projetos mastodnticos: 1000 pessoas envolvidas ou mais. Mas ele lembra que desde aquela poca os gerentes de programao preferiam "pequenos e 'agudos' times formados por pessoas de 'primeira classe'". Brooks cita um estudo (de Sackman, Erikson e Grant [2]) 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 clculos do autor. Por outro lado Brooks lembra que times grandes, orientados para a execuo de um trabalho na base da 'fora bruta', so "lentos, caros, ineficientes, e produzem sistemas que no possuem 'integridade arquitetnica'. OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE, etc. A lista longa". E "o dilema cruel", escreve Brooks. Haveria soluo?

* Curiosidade: em 30 anos o salrio anual de um bom engenheiro saltou de US$20 mil para US$ 80 mil nos EUA. O cafezinho do Antoine custava US$0,20. Hoje vendido por US$2,75!

16/60  16/60 

A sugesto de Brooks, baseada em uma proposta de Harlan Mills [3], d ttulo para o terceiro captulo do seu livro, "O Time Cirrgico". Segundo ele, o time ideal formado por:
D Programador Chefe (Cirurgio) D Co-Piloto D Administrador D Editor D Secretrias (duas) D Bibliotecrio D Almoxarife D Testador D Advogado (da Linguagem)

Reparem bem. Ns temos praticamente 9 pessoas trabalhando para o programador! Dando-lhe "todo suporte que far aumentar sua eficcia e produtividade". Lembram-se que o Brooks tambm sugeria que alocssemos apenas 1/6 de nosso cronograma para tarefas de codificao? Outro mundo, no mesmo? Pode e deve ser factvel em um time cirrgico de verdade mas aplica-se a equipes montadas para o desenvolvimento de sistemas?

17/60  17/60 

O 'cirurgio' seria responsvel pela execuo de todas as tarefas principais daquela parte do projeto: sua especificao, design, codificao, testes e documentao. No difere muito de alguns job descriptions e anncios de vagas que ainda vemos por a. Seria um "analista-programador" que, segundo Brooks, deveria ter 10 anos de experincia. O mundo da programao mudou muito desde os tempos do COBOL e da PL/I. A complexidade e abrangncia de nossas linguagens e arquiteturas de aplicaes aumentaram 'para os lados e para baixo'. E cada vez mais comum que cada uma das tarefas listadas acima seja atribuda a um especialista. Uma diviso que ntida em fbricas de software, por exemplo. Em caminho oposto, alguns advogados de mtodos geis enaltecem a importncia de um time formado por 'generalistas'. A analogia com equipes mdicas reaparece em um artigo de Peter Drucker publicado pela Harvard Business Review em 1988, "O Advento da Nova Organizao" [4]. Segundo Drucker, "informao dado investido de relevncia e propsito. Por conseguinte, a converso de dados em informao requer conhecimento. E conhecimento, por definio, especializado. (Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especializao, qualquer que seja seu campo de atuao, exatamente porque sempre se deparam com muito mais a aprender)." Apesar de ser simptico aos chamados mtodos geis, no acredito na possibilidade ou eficcia de um time composto por generalistas. Prefiro apostar em uma formao que valorize o perfil e a experincia de cada um de seus membros. No diagrama abaixo apresento um exemplo de um time estruturado por especializaes:

18/60  18/60 

O arquiteto o novo 'cirurgio'. o dono e principal responsvel por aquele projeto ou mdulo. Mas s coloca 'a mo na massa', codificando, para transferir conhecimentos. Ocupa-se com a concepo e manuteno da integridade arquitetnica da soluo. Ele diretamente apoiado por cinco especialistas:
D Analista de Negcios (biz): cuida da coleta e organizao dos requisitos, e apia seu

desenvolvimento, fazendo a ponte entre os usurios e a equipe de desenvolvimento;

D Desenvolvedor de Interfaces (front): especialista em usabilidade e 'manda bem' em conceitos de

arquitetura de informaes. Hoje deve 'brincar' com AJAX (Javascript), Flash, HTML, CSS, ASP, JSP, JSF e afins.
D Desenvolvedor de Servios (srv): domina orientao a objetos, componentizao e, mais

recentemente, servios. um programador clssico que, como tal, no leva o menor jeito com as 'frescuras da camada de apresentao'.
D Arquiteto de Informaes (data): uma verso remoada dos DBA's (administradores de bancos de

dados). Domina o desenho e desenvolvimento de bases tradicionais, transacionais, mas tambm sabe quando lanar mo de sistemas gerenciadores de contedo e bases analticas.
D Nosso antigo inimigo (infraestrutura): so os responsveis por nossos servidores, redes, firewalls e

outros brinquedinhos. T-los como parte da equipe de projeto desde os primeiros dias uma prtica que, com certeza, minimiza aquele 'jogo de empurra' que costuma acontecer um pouco antes ou um pouco depois do delivery da soluo.

19/60  19/60 

Mas... e o coordenador? No prximo sub-captulo falo especificamente sobre ele e sua convivncia com o arquiteto. Agora, seguindo com o time cirrgico proposto por Fred Brooks. O co-piloto que ele sugere o 'alter ego' do cirurgio, capaz de executar qualquer tarefa atribuda a este. A nica diferena que o co-piloto seria menos experiente. Mas, ainda assim, funcionaria como um backup do cirurgio, inclusive representando-o em reunies com outras equipes. Porm sua principal funo avaliar e discutir as idias do programadorchefe. Lembra (vagamente) uma das prticas sugeridas pelo mtodo conhecido como eXtreme Programming (XisP - para os ntimos), a Pair Programming. O Administrador sugerido por Brooks um tipo de Coordenador do Projeto. Apesar do cirurgio ter a palavra final em todas as questes, o administrador que cuida do dia-a-dia da gesto financeira, de pessoal, suprimentos etc. Mais sobre o assunto no sub-captulo seguinte. O Editor o responsvel pela documentao. O cirurgio, segundo a proposta de Brooks, gera os documentos principais, tanto os tcnicos quanto aqueles para os usurios finais. Mas seria o editor o responsvel pela compilao final, anexao de referncias, bibliografia etc. um luxo. Porm, ainda hoje brigamos para obter bons documentos de bons programadores, inutilmente. O Bibliotecrio - 'escriturrio', ou program clerk, como sugerido por Brooks, parece no fazer muito sentido nos dias de hoje. Mas parecia ser crucial nos tempos dos cartes perfurados e das interminveis listas impressas em formulrios contnuos. No entanto eu acredito que toda organizao que esteja

20/60  20/60 

buscando o reuso de seus ativos de software, ou implantando uma SOA (Arquitetura Orientada a Servios), demandar a presena de um bibliotecrio, um especialista que em outro artigo eu chamei de GBA (Gestor da Biblioteca de Ativos). Se prestarmos ateno na complexidade dos atuais ambientes integrados de desenvolvimento (IDEs Integrated Development Environment), com seus frameworks, testes automticos, integrao 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 adequao para cada tipo de projeto e funo. Em equipes grandes ou em 'fbricas', parece ser uma funo de grande utilidade. O Testador o nosso "Engenheiro de Testes", uma funo que aos poucos vai se tornando mais comum. Pena que muitos ainda o confundam com um 'programador que no deu certo' ou com programadores iniciantes. Teste coisa sria, tanto que Brooks, como mostramos na 1 parte do artigo, dedicaria 50% do esforo de um projeto exclusivamente para ele. Por fim Brooks sugere a alocao de um 'Advogado da Linguagem'. Creio que nossos espertssimos e modernos IDE's, nossos 'testadores' e, lgico, o arquiteto, eliminam a necessidade de um 'language lawyer'. Advogado no, n?

21/60  21/60 

Os Dois Donos do Projeto

Fred Brooks encerra "O Time Cirrgico", terceiro captulo de "The Mythical Man-Month", falando que um sistema deve ter total Integridade Conceitual, e que isso s seria possvel atravs da dedicao integral de um Arquiteto (System Architect, no texto original). Logo depois, em "Por que a Torre de Babel falhou?", ele fala de dois lderes em um projeto: o Arquiteto (ou Diretor Tcnico) e o Produtor. Mas o dito popular no ensina que Tot com dois donos morre de fome? Como um projeto pode ter dois lderes e no parecer uma organizao confusa? Segundo Brooks, o Produtor o cara que monta o time, divide as tarefas e elabora o cronograma. Tambm ele quem cuida da aquisio de recursos durante todo o projeto. Portanto, na maior parte do tempo, o Produtor estaria interagindo com entidades externas ao projeto. Ainda assim, ele quem estabelece padres de comunicao e relatrios com o time. J o Arquiteto (ou Diretor Tcnico) responsvel pelo desenho do sistema a ser construdo, seus mdulos e tambm seu aspecto exterior. Interage principalmente com o time, resolvendo questes tcnicas. Considerando que os dois perfis so necessrios em projetos de qualquer porte, Brooks aponta trs relacionamentos possveis entre eles:

22/60  22/60 

D Arquiteto e Produtor so a mesma pessoa: possvel em pequenos projetos (para Brooks, de 3 a 6

programadores). Mas uma combinao arriscada em projetos maiores. Brooks justifica: "Pensadores so raros; executores so raros; pensadores-executores so rarssimos".
D O Produtor o chefe e o Arquiteto o seu brao direito: a dificuldade aqui, segundo Brooks, o

estabelecimento da autoridade do Produtor em questes tcnicas. Ele diz que o entrosamento entre o Produtor e o Arquiteto fundamental. E que o primeiro deve respeitar muito o valor do arquiteto.
D O Arquiteto o chefe e o Produtor o seu brao direito: segundo Brooks, este seria o arranjo ideal

para equipes pequenas, enquanto o anterior (Produtor o chefe) funcionaria melhor em projetos maiores. impossvel evitar o paralelo das sugestes de Fred Brooks com aquelas apresentadas por Jeff Sutherland (depois de Takeuchi e Nonaka [5]) em seu mtodo chamado Scrum. Jeff Sutherland, ao contrrio de Brooks, no deixa dvida sobre quem fala mais alto em um projeto. O Arquiteto, que no Scrum chamado de Product Owner, tem a palavra final. Enquanto o Coordenador (Produtor), ou Scrum Master, trata de eliminar riscos e obstculos que estejam impedindo o time de obter sua melhor performance. So, respectivamente, o Navegador e o Piloto em uma equipe de rally, uma analogia criada pelo prprio Sutherland. Este desenho faz lembrar tambm uma colocao de Tom DeMarco em um de seus principais trabalhos, "Peopleware"[6]:

"A funo do gerente no fazer as pessoas trabalharem e sim tornar possvel que elas trabalhem."

23/60  23/60 

Podemos perceber o mesmo tipo de separao de funes e responsabilidades na indstria cinematogrfica. O diretor do filme (arquiteto) tem a palavra final sobre todos os aspectos da criao. E os produtores (coordenadores) tratam do dia-a-dia do projeto. Antes de encerrar o tema uma observao: Fred Brooks, assim como Scott Berkun, trabalhou na indstria, desenvolvendo produtos. Falta em seus 'job descriptions' do Arquiteto e do Produtor (Coordenador) a preocupao com um Cliente. Parece bvio que o chefe, seja ele o Arquiteto ou o Coodenador, seja a principal interface da equipe do projeto com o cliente. Eu prefiro deixar que o Coordenador seja sempre o canal de contato principal com o cliente, independente de ter ou no a palavra final no projeto. As questes tcnicas e funcionais, na maior parte das vezes, deveriam ser solucionadas (ou melhor, direcionadas) pelo Analista de Negcio, apresentado no sub-captulo anterior.

24/60  24/60 

A Outra funo da Organizao

Quando falamos em Organizao, Estrutura, a primeira imagem que aparece a de um organograma. Preocupamo-nos, quase que exclusivamente, em saber quem que manda no pedao e quem deve (ter o juzo de) obedecer. Fred Brooks diz que precisamos aprender a desenhar estruturas e processos que incentivem, e no que inibam a criatividade e a iniciativa. E lembra: "a Criatividade vem dos indivduos e no das estruturas e processos". Scott Berkun segue linha parecida dizendo que os "projetos dependem muito da habilidade do time em fazer uso do conhecimento de seus membros, de compartilhar idias e trabalhar em sincronicidade, ao invs de seguir restritivas linhas de autoridade, uma rigorosa disciplina e uma compulso a seguir ordens sem nenhum tipo de questionamento". Esse embate muitssimo bem documentado por Domenico de Masi no livro "Criatividade e Grupos Criativos"[7]. Domenico afirma que atravessamos uma fase caracterizada por um Cultural Gap, um fenmeno que "constrangeu os atuais knowledge workers, os trabalhadores do conhecimento, a se organizarem segundo os velhos princpios industriais". Que seja s uma fase. Mas ainda no h muitos indcios de que esteja para terminar. Por exemplo, o termo fbrica de software de uma infelicidade incrvel. Um oxmoro, no meu ponto de vista. Por outro lado temos a consolidao de produtos como Linux, Apache, Eclipse e Firefox, que so criados em ambientes onde parece imperar o caos. Deve haver um meio termo, no?

25/60  25/60 

Castelos de Areia...
Em 1986 Fred Brooks publicou o artigo "No Silver Bullet", que aparece como o captulo 16 da edio que comemorou os 20 anos de "The Mythical Man-Month". Para Brooks, "ainda cometemos erros de sintaxe, com certeza, mas eles no so nada quando comparados aos erros conceituais da maioria dos sistemas". Scott Berkun cita Brooks na abertura do captulo "How to figure out what to do", o terceiro de "The Art of Project Management": "A parte mais difcil da construo de software decidir o que construir. Nenhuma outra etapa do trabalho conceitual to difcil quanto a fixao dos requisitos tcnicos detalhados, incluindo todas as interfaces com usurios finais, com mquinas e outros sistemas. Nenhuma outra etapa compromete tanto o projeto se executada erroneamente. Portanto, a funo mais importante que o construtor de software executa para seu cliente a extrao iterativa e o refinamento dos requisitos do produto". Para Brooks, trata-se de uma funo 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 soluo. A separao desta etapa, quando decidimos 'o que deve ser construdo', da etapa de implementao, quando decidimos 'como construir', seria outra forma poderosa de buscar tal integridade.

26/60  26/60 

Berkun chama de 'insanamente simples' a forma como ele v a etapa de planejamento de um projeto. Ela representada no grfico abaixo:

E, seguindo em sua 'insanidade', Berkun justifica a necessidade de Planos. Segundo ele, os planos "funcionam como um remdio contra todo tipo de estupidez porque foram que questes importantes sejam resolvidas enquanto h tempo para considerar outras opes". Apesar de uma (sutil) diferena, ambos os autores concordam com a separao das fases de Arquitetura (ou o que, coleta de Requisitos, Definio etc) e de Especificao (ou como, design/especificao etc). Uma distino bvia, simples, mas deveras negligenciada. Quantas e quantas vezes testemunhamos 'arquitetos' (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 soluo o Manual, uma especificao de toda a parte externa de um sistema. o manual do usurio mesmo, nas fases iniciais de um projeto! Um documento que no deveria se preocupar em explicar os comos.

27/60  27/60 

As Vises e o Documento de Viso

Berkun um pouco mais metdico e indica a necessidade de 4 documentos principais. Antes, porm, ele alerta para a criticidade do balanceamento de trs perpectivas:
D Negcio: "... quando equipes de engenharia ignoram como seu negcio funciona, muitas decises da

gerncia parecero ilgicas ou estpidas";

D Tecnologia: "... o mindset de construo e materiais. Tem o foco em como as coisas devem ser

feitas";
D Cliente: "A mais importante das trs perspectivas... Mas, infelizmente, a mais fraca em muitas

organizaes." Segundo Berkun, as trs perpectivas sempre se sobrepem. "Cada considerao 'de negcio' tem implicaes Tcnicas e para o Cliente (e assim por diante)". E cada deciso pode favorecer determinado ponto de vista, em detrimento de outro. "Ao investir tempo explorando cada uma das perspectivas", diz Berkun, " possvel ver oportunidades para melhores decises estratgicas". Para Berkun, a fase de planejamento de um projeto s se encerra quando os 4 documentos propostos por ele esto prontos. Ou, em suas palavras: quando "as decises que eles contm esto tomadas". Os documentos so:

28/60  28/60 

D Marketing Requirements Document (MRD)

Trata-se da Viso do Mundo apresentada pelo negcio ou sua equipe de marketing. Apresenta os objetivos do negcio e ajuda a definir "o que" o projeto deve contruir visando sua satisfao;
D Documento de Viso (Escopo)

Define os objetivos do projeto, explica sua lgica e apresenta caractersticas (em alto nvel), requisitos e datas. Definem diretamente "o que" o projeto deve realizar;
D Especificaes

Define o "como" de um projeto, com uma perspectiva de design e engenharia;

D Work Breakdown Structure (WBS)

Mostra como o time trabalhar para realizar o projeto.

Berkun tambm parece cair na 'armadilha' waterfall quando prope 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 elaborao. No deveriam ser apenas os 'acidentes' (tambm conhecidos como 'mudanas') que nos foram a voltar a tais documentos (tal fase). Se o MRD (que pode ser um RFP Request for Proposal, por que no?) (ou pelo menos deveria ser) elaborado pelo Cliente, temos que o primeiro documento confeccionado pelo time do projeto o Documento de Viso. Segundo Berkun, alm de apresentar e explicar todas as caractersticas (features) do produto a ser gerado, como no Manual sugerido por Brooks, o documento deve:

29/60  29/60 

D Explicar o projeto em apenas uma sentena (uma 'declarao de viso'); D Mostrar como o projeto contribuir para a satisfao dos objetivos do negcio; D Apresentar as caractersticas/cenrios essenciais para os Clientes (prioridade 1); D Mostrar as caractersticas/cenrios considerados 'desejveis' mas no essenciais (prioridade 2); D Apresentar os clientes e os problemas que o projeto deve solucionar para eles; D Bem como apresentar os atores (stakeholders); D Explicar por que os clientes comprariam (ou alugariam) o produto do projeto; D Apresentar os concorrentes e uma comparao de seus produtos com aquele que o projeto deve

gerar;
D Explicitar o que est "fora do escopo" do projeto; D Mostrar quais os riscos do projeto; D Suas dependncias externas (sub-contratados e afins); D Em alto nvel, como o trabalho ser organizado; e D Apresentar todas as suposies e dependncias.

Ou seja, o Documento de Viso, como proposto por Berkun, compila todas as informaes e decises elaboradas no planejamento inicial de um projeto. Esta compilao, escrita de forma a ser acessvel/legvel para todos os atores de um projeto, se torna um dos principais meios de comunicao/negociao com os clientes. No entendo porque Berkun no sugere a insero de um cronograma. Outra alterao que eu faria a criao de uma 'prioridade 3', com a lista de todas as caractersticas/cenrios classificados como 'perfumaria' ou suprfluos. Eles sempre esto l. s uma questo de classific-los.

30/60  30/60 

Berkun sugere que 5 iteraes seriam suficientes at a gerao de uma verso final do Documento de Viso. Acho arriscado fixar assim o nmero de 'verses'. Cada projeto pode determinar um ritmo/ciclo bastante particular. Mas creio que um mnimo de 3 iteraes sejam necessrias. O trabalho nas Especificaes e na WBS gerar, sem dvidas, alteraes na Viso. Por fim, Berkun destaca as 5 qualidades de uma "Boa Viso":
D Efeito Simplificador; D Apresenta de 3 a 5 objetivos de alto nvel; D Consolidada; D Inspiradora; e D Memorvel.

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 Viso so muito ruins. Ele tem trs teorias para o problema:
D A falta de um 'autor-lder' que, no meu ponto de vista, deveria ser o prprio Arquiteto; D Os documentos no seriam escritos para servir ao leitor, denotando falta de compreenso e de

interao com o cliente; e

D A confuso entre 'hype' e realidade, que geraria documentos meio 'marketeiros' e pouco objetivos.

31/60  31/60 

Vai Entender o que o Cliente Quer

Scott Berkun dedica vrias pginas de seu livro para tratar da tal 'Engenharia de Requisitos' (termo que ele no utiliza) e do 'Design' (termo que ele usa insistentemente) de uma soluo. Captulos como "How to figure out what to do", "Where Ideas come from" e "What to do with ideas once you have them" do 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 funes relacionadas esses tipos de levantamentos deveramos alocar dois tipos de experts: Engenheiros de Usabilidade e Designers de Produtos. Mas Berkun observa: "Mesmo que na ltima dcada muito progresso tenha sido feito no refinamento de mtodos de pesquisa e compreenso de clientes, grande parte dele no foi assimilado pelo corpo gerencial ou em organizaes 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 deciso". Na sugesto que apresentei na 2 parte desta srie, o Desenvolvedor de Interfaces realiza tais funes. Trabalhando bem prximo do Analista de Negcios.

32/60  32/60 

Muito se fala, e eu no tenho dvidas, de que o tema requisitos responde por mais de 50% dos problemas em nossos projetos. Berkun nos apresenta 5 dicas para a obteno do que ele chama de "Requisitos de Alta Qualidade":
D Planeje as negociaes de requisitos e as iteraes

Identificados nossos clientes e demais atores do projeto, torna-se factvel a elaborao de uma Agenda para a Coleta de Requisitos. No pior cenrio, uma RFP deve dar pistas suficientes para o rascunho de um plano inicial.
D Elimine as Suposies Erradas

Como identific-las? S perguntando. Como diz o Berkun, "se voc o coordenador do projeto ... religiosamente faa perguntas esclarecedoras, como 'por que precisamos disso?', 'que problema isso resolve?'", e assim por diante. S no permita que seu time assuma como verdadeiras solicitaes que podem nem mesmo ter partido do cliente, ou dos verdadeiros usurios.
D Busque as Informaes que Faltam

"Os mais notveis erros em requisitos so erros de omisso". A coleta e anlise bem realizadas devem tornar bem visveis todas as peas que faltam no tabuleiro do projeto.
D Defina Prioridades Relativas para todos os Requisitos

Costumo solicitar, ainda na coleta, que o cliente/usurio defina se aquela solicitao Fundamental, Importante ou Acessria. Uma classificao clara e simples assim ajuda muito em diversas tomadas de deciso.
D Refina ou Elimine a Linguagem Ambgua no-Intencional

"Palavras como rpido, grande, pequeno, bonito e usvel requerem mtricas relativas para serem entendidas. Em alguns casos, pode ser do interesse de todos que elas permaneam 'em aberto' at momentos posteriores do projeto". Mas, a princpio, devemos eliminar toda redao que no permita um entendimento nico de um requisito.

33/60  33/60 

Cabe aqui outra intromisso minha. Ainda h muito trabalho a ser realizado antes do Analista de Negcios/Sistemas repassar os requisitos para o time de Arquitetura da Soluo. As dicas do Berkun listadas acima so teis mas no suficientes. No meu ponto de vista, todos os requisitos coletados devem ser estruturados, formando uma Base de Conhecimentos do projeto. 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 sugesto de um modelo 'mnimo'. Em "Requirements-Led Project Management" [8], 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 invs de documentos textuais ou planilhas eletrnicas, mais gerencivel. Fica mais fcil manter a tal rastreabilidade bi-direcional dos requisitos e tambm 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 mnima alterao na redao do requisito ou em algum de seus atributos significa a insero de um novo requisito, que substitui o anterior mas mantm um vnculo. Assim conseguimos rastrear todas as mudanas que ocorreram desde os instantes iniciais de um projeto. Portanto a base de conhecimentos acaba se tornando um dos, seno o principal subsdio para o Gerenciamento de Mudanas (tema do prximo captulo).

34/60  34/60 

Perdidos no Espao (entre os Requisitos e a Soluo)

Constatao inquietante de Berkun: "Por razes que no consigo explicar totalmente, muitas pessoas tm dificuldade com o planejamento do trabalho criativo. Na maioria dos livros que li sobre gesto 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 estaro finalizados, e outra data para quando as especificaes supostamente estaro prontas, mas poucas instrues so fornecidades para a execuo daquilo que est entre essas duas datas". Para Berkun, to logo estejamos com os requisitos 'no lugar', "os designers podem explorar o territrio desenhado pelos requisitos. H um largo espao, chamado 'Espao do Problema', de maneiras potenciais para resolver o problema colocado. Dependendo dos requisitos, este espao pode ser bem grande; por exemplo, h um infinito nmero 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 noo das possibilidades que existem, no 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 Idias apaixonante para alguns e apavorante para outros. As idias vm das pessoas, lembra Berkun: "nenhuma idia na histria da humanidade brotou de uma pilha de pedras, ... , de livros de auto-ajuda, de seminrios de criatividade ou de sesses de brainstorming".

35/60  35/60 

Por que ento a fase de design (Arquitetura da Soluo) seria to negligenciada? Para Berkun, "talvez seja porque as pessoas temem a explorao [de idias], especialmente quando esto sendo observadas". Berkun diz ter "evidncias irrefutveis de que h um nmero infinito de idias prejudiciais, horrveis, inteis, comicamente estpidas e embaraosamente ruins". Ele solta essa prola ao questionar a mxima (segundo ele oriunda de comerciais de TV e de sesses de brainstorming ou de comerciais de TV vendendo sesses de brainstorming) que diz que "no existem ms idias". Lgico que elas existem. Aos borbotes. Dentre outras coisas, ele sugere algo muito simples: "Boas perguntas atraem boas idias!" Para Berkun existem dois tipos de perguntas 'Boas' e um tipo de pergunta 'Ruim' quando estamos envolvidos em um trabalho criativo:
D Perguntas Direcionadoras (Boas)

"Chamam a ateno do time para algo importante, til ou mesmo central para o trabalho em execuo". Tipo: Como o usurio saber que deve clicar neste boto para ir para a prxima tela?
D Perguntas Criativas (Boas)

Ao contrrio das questes direcionadoras, estas devem "levar o time para territrios ainda no explorados do problema em questo". Algo como: Havero outros meios para o cliente chegar na prxima tela?
D Perguntas Retricas (Ruins)

"Gmeas das questes criativas, diferenciam-se pelo fato de serem insinceras, perguntadas sem a inteno 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?

36/60  36/60 

Mas, independente da qualidade (e da inteligncia) de nossas perguntas, devemos esperar diversas idias 'ruins, comicamente estpidas, hilariantes' etc. Triste o ambiente pouco tolerante a elas, porque, alm de sisudo e montono, inibe a participao de todos os membros da equipe, mina o esprito de colaborao que deveria existir durante todo o projeto. Alm de desperdiar boas piadas, n? Seguindo com Berkun: " melhor que a gente suje as mos e cometa vrios erros nesta fase. Quanto antes isso acontecer, mais rpido a gente chega s boas idias."

"As duas mais importantes ferramentas de um arquiteto so a borracha na sala de desenhos e a marreta na construo" - Frank Lloyd Wright "A mais importante ferramenta do fsico sua cesta de lixo." - Albert Einstein

Berkun tambm detona outro 'mantra', comum em certos crculos por a, o tal "think outside the box": "No a eliminao das caixas a parte mais difcil exatamente saber quais caixas utilizar e quando. Restries estaro sempre presentes". E completa: "faa o que voc quiser com a caixa. Pense dentro da caixa, fora da caixa, debaixo da caixa, corte-a e faa fogo com ela, qualquer coisa, desde que voc gerencie para resolver os problemas identificados como crticos para o projeto".

37/60  37/60 

O Problema do Tamanho do 'Espao do Problema'

"Idias fogem do controle", diz o ttulo de um sub-captulo do livro de Berkun. Por isso, "se difcil encontrar boas idias, 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 questo Berkun apresenta o grfico abaixo:

A partir de uma slida base de (bons) requisitos, comeamos a explorar alternativas de soluo. Com o passar do tempo a tendncia que o nmero de alternativas (cenrios) aumente. Aumentamos assim o tamanho do 'Espao do Problema'. Um dos riscos, segundo Berkun, no saber o momento de parar com a gerao de idias e comear a filtr-las. Para tal Berkun sugere a fixao de alguns pontos de checagem.

38/60  38/60 

Como ilustra o grfico abaixo, so 6 os grandes check-points que deveriam nos guiar no processo de arquitetura da soluo:

a. Viso e Prova de Conceito Nosso ponto de partida deveria ser um documento de viso e uma prova de conceito. Traduzindo para Pindorama: ser a tal 'proposta tcnica' para muitos corajosos colegas. b. Agrupamentos de Idias Depois de um certo tempo jogando conversa fora, digo, idias 'para fora', conveniente que elas sejam agrupadas e analisadas. c. Trs 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 viveis. d. Duas Alternativas Pouco tempo depois deveramos ser capazes de escolher apenas 2 alternativas de implementao. e. Um Design E ento apenas um design (ou Arquitetura da Soluo). f. Especificaes Ento, com a Arquitetura definida, geramos a especificao tcnica da soluo.

39/60  39/60 

... E a inevitabilidade das Mars

"O primeiro passo aceitar as mudanas como um estilo de vida, e no como um desvio, uma exceo". Assim, de forma simples e direta, Fred Brooks comea a tratar o tema "Mudanas". Mudanas ocorrero em um projeto no s porque o trabalho inicial (coleta e anlise de requisitos e arquitetura da soluo) no foi bem feito. Segundo Brooks, "a entidade Software est sempre sujeita a presses por mudanas. Claro, como prdios, carros e computadores. Mas coisas manufaturadas raramente mudam aps sua produo". J o software sim, dada sua "infinita maleabilidade". No carecemos nem mesmo das borrachas e marretas de Frank Lloyd Wright. "Longe de mim", diz Brooks, "sugerir que todas as mudanas de objetivos do cliente podem ou devem ser incorporadas ao desenho da soluo. Um delimitador deve ser estabelecido, e ele deve ficar mais restritivo na medida em que o desenvolvimento avana, ou o projeto nunca terminar". O delimitador parece bvio na teoria, mas pea rara na prtica. Se a mudana solicitada for crucial para o pleno atendimento das necessidades de negcio, o que fazer? Ignor-la? Dizer que ela ser implementada na '2 verso'? Toda solicitao de mudana deve ser analisada com carinho, independente do que estejam indicando o termmetro e o taxmetro do projeto. Independente da fase do projeto e da fase da lua.

40/60  40/60 

Para Scott Berkun toda solicitao de mudana deveria seguir o mesmo processo de negociao que guiou a fase inicial de coleta de requisitos. Creio que a assimilao do processo se torna mais simples se entendermos que toda solicitao de mudana nada mais que um novo requisito. Ou, em muitos casos, uma 'nova verso' de um requisito. Quando executamos corretamente a Engenharia de Requisitos, avaliamos os impactos que cada nova solicitao pode causar naquelas previamente coletadas. Agora, recebendo um change request, executaramos o mesmo tipo de anlise. Dependendo do porte do projeto e do nmero de dependncias (grau de acoplamento) dos requisitos, tal avaliao pode ser penosa e demorada. inevitvel? Berkun sugere um breve check-list para uma avaliao prvia dos requisitos que apareceram fora de hora:
D Qual problema estamos tentando resolver? Precisamos resolv-lo para obtermos sucesso? Precisamos

resolv-lo na iterao atual? Podemos viver com o problema?

D Trata-se de um sintoma ou uma causa? aceitvel que tratemos apenas o sintoma? D Temos noo do impacto desta mudana? D O custo da mudana ser compensado pelo benefcio gerado? D E os riscos de novos problemas so compensados pelo benefcio da mudana?

A menos que a solicitao de mudana seja absurdamente ridcula, a execuo do check-list acima no ser rpida e muito menos trivial. Por isso cabem aqui dois alertas: i) O cliente, ou usurio ou o stakeholderZezinho que solicitou a mudana deve participar do processo acima. Ele precisa ter noo do 'estrago que est prestes a causar'. E ser co-responsvel por ele; e ii) O processo de desenvolvimento em uso (a metodologia) deve tentar programar o momento certo para a avaliao das mudanas solicitadas.

41/60  41/60 

Como foi apresentado na 1 parte desta srie, quanto maior a incerteza (a volatilidade dos requisitos), menor deve ser a durao de uma iterao. No mundo ideal, todas as solicitaes de mudanas so analisadas no momento em que a equipe planeja a prxima iterao. Se uma triagem foi executada anteriormente pelo coordenador ou analista de negcios, em conjunto com o Zezinho, ento no o mundo ideal. o paraso mesmo. Scott Berkun apresenta ento uma forma muito simples de gesto de mudanas, que ele chama de "verso super-lean do processo de especificao". Consiste do seguinte: 1. O Coordenador do Projeto (ou o Analista de Negcios - interferncia minha), escreve um sumrio da mudana solicitada, incluindo sua relao com os objetivos do projeto e com os requisitos previamente apresentados; justifica a necessidade da mudana; e apresenta o desenho da mudana a ser implementada. Berkun sugere que este documento tenha no mximo duas pginas; 2. O programador, o testador e todos significativamente impactados pela solicitao devem analisar o documento gerado e dar suas contribuies. As mais notveis (e ansiosamente aguardadas por todos) so as estimativas de desenvolvimento e testes. 3. O documento finalmente apresentado aos lderes do projeto (e, como sugeri anteriormente, ao cliente, usurios, zezinhos etc). Nessa breve reunio a mudana aceita ou no. Se recusado, diz Berkun, "o documento deve rastejar at o canto mais prximo e, soluando incontrolavelmente, desaparecer do universo do projeto".

Insisto que a reunio citada no item 3 acima deveria ser programada e tratar de um conjunto de solicitaes de mudanas. Se executada ad hoc e a granel, se transformar rapidamente no 'inferninho' do projeto.

42/60  42/60 

Fred Brooks cita um estudo de Lehman e Belady [9] que mostra que em cada nova verso o nmero de novos mdulos cresce linearmente, mas o nmero de mdulos afetados pelas mudanas aumenta exponencialmente. Todas as correes e alteraes de rumo (em relao arquitetura original) "tendem a destruir a estrutura, a aumentar a entropia e desordenar o sistema". O divisor de guas, a separao entre mars (mudanas) benficas e tsunamis detonantes, deveria ser mais ntido. Mas a prtica prova que no . Est no discurso de todos os processos modernos que devemos aceitar as mudanas. Afinal, elas so inevitveis. Mas sabemos que alguns change requests podem simplesmente inundar o projeto com efeitos colaterais mortais. O que permite sua distino? Como avaliar corretamente o impacto e os riscos de uma mudana? Creio que impossvel sem uma clara viso da arquitetura do sistema. Um modelo detalhado, que exponha todas as interfaces entre todos os mdulos, parece ser a melhor vacina contra mudanas malficas. Mas um modelo s mede o impacto das mudanas na arquitetura do sistema. E os planos, cronogramas, agendas e finais de semana prolongados? Como ficam?

43/60  43/60 

Planejar ou no Planejar? uma questo?

Apesar de demonstrar uma certa simpatia por XP (eXtreme Programming) e suas breves iteraes, Berkun refora a utilidade dos planos de longo prazo: "mesmo quando eles so grosseiros, eles tornam as mudanas de curto ou mdio prazos mais fceis". E justifica: "quando uma mudana nos objetivos, requisitos ou no design ocorre, raramente o plano original vai parar na lixeira". O plano original talvez seja nossa melhor (seno nica) base de comparao para uma correta avaliao das mudanas 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 captulo de seu livro que trata de forma mais especfica o tema mudanas chama-se "Middle-Game Strategy". Cada deciso do gerente do projeto, assim como cada movimento de um enxadrista, s pode assumir uma de duas caractersticas possveis:
D Conservadora: deixa-o com o maior nmero possvel de 'movimentos futuros', de opes. Em um

projeto pode significar uma desacelerao do ritmo. Mas, escreve Berkun, "este o preo do seguro que voc est comprando".
D Agressiva: mostra total domnio e comprometimento com uma estratgia. O gerente confia em seu

plano e em sua 'fora'.

44/60  44/60 

A ausncia de um plano no permite nem mesmo avaliar o perfil das decises do gerente do projeto. E a maneira como elas so apresentadas pode ser um pssimo 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 realizao de dois check-lists para a verificao de nossa sanidade, digo, da sanidade do projeto. O primeiro ttico (dirio), e apresenta as seguintes questes:
D Quais so nossos objetivos e compromissos? Eles ainda so vlidos?

No meio de tanto trabalho, diz Berkun, " muito fcil perder os objetivos de vista". Olhar para eles diariamente uma forma de manter o foco e avaliar corretamente as prioridades.
D O que estamos realizando hoje contribui para a realizao dos objetivos?

claro como os trabalhos em execuo contribuiro para a satisfao dos objetivos e dos requisitos? Se no, diz Berkun, "o barco t comeando a ficar deriva".
D Os trabalhos esto sendo concludos de forma a satisfazer os requisitos e cenrios?

"H mil maneiras de completar uma unidade de trabalho que no satisfaz o esprito e a inteno do design", lembra Berkun. Sabemos que a distncia entre o t pronto do programador e o t pronto do usurio pode ser quilomtrica.

O outro check-list estratgico e, segundo Berkun, deveria ser executado semanalmente ou mensalmente, seja em reunies de discusso do status do projeto ou mesmo individualmente. As questes so:

45/60  45/60 

D Qual a probabilidade de atingirmos o prximo milestone com o apropriado nvel de qualidade?

Com certeza aconteceram mudanas desde o trabalho de estimativas. E mesmo que no, no custa nada perguntar ao time se o cronograma segue verdadeiro e exequvel.
D Quais ajustes so necessrios para aumentar tal probabilidade?

Berkun diz que " raro obter 100% de confiana na prxima data de qualquer um que seja honesto e so". Portanto esta pergunta (quase) sempre ser colocada.
D Como executar tais ajustes com cuidado e de forma isolada?

"Um telefonema? Um email? Despedindo algum?". Berkun alerta que devemos pensar de forma 'cirrgica', mas no devemos temer as aes e decises que precisam ser executadas/tomadas.
D Quais so os maiores ou mais provveis riscos que enfrentamos hoje, na prxima semana ou no

prximo ms? E quais so as contingncias? A simples identificao dos maiores ou mais provveis riscos j , de acordo com Berkun, um grande passo no sentido de preven-los.
D O mundo mudou e eu no estou sabendo?

Os patrocinadores ainda so os mesmos? E seus objetivos, mudaram? O time se preocupa com algo que eu no conheo? Nossas antenas e sentimentos devem estar atentos para mudanas que ocorram tanto no micro-universo quanto no macro-universo do projeto.

Na sequncia do mesmo captulo de "The Art of Project Management Scott Berkun apresenta vrias outras ferramentas para o (micro) gerenciamento (dirio) do projeto. Brinquei com os parnteses para destacar a mensagem: gerenciar um projeto significa (tentar) cuidar de um nmero imenso de varaveis, a maioria delas muito pequena e volvel, durante todo o dia. Todos os dias.

46/60  46/60 

A Receita e o Bolo de Fub

Quando pensei no ttulo deste ltimo captulo busquei algo que fosse extremamente simples, uma receita culinria de um prato bem 'default'. Mas que ao mesmo tempo parecesse nico em cada fornada. O bolo de fub foi uma lembrana imediata. Nunca vi dois iguais. Mais seco, mais molhado, dois ou quatro ovos, com queijo ou no... com vinagre!?! Pois , achei mais de 30 mil ocorrncias para bolo de fub no Google. Minha famlia (mineira, obviamente) compartilha uma mesma receita. Mas o resultado sempre diferente. Para algo que deveria ser incrivelmente simples: so s nove ingredientes. Um mesmo processo. Um mesmo cronograma. Mas, surpreendente mesmo a iluso que todos ns que lidamos com desenvolvimento de sistemas j alimentamos pelo menos uma vez na vida: a iluso de que existiria uma receita mgica, uma "bala de prata", que nos ajudaria a entregar nossos projetos no prazo, dentro do oramento e excedendo todas as expectativas de nossos clientes e usurios. Se quase impossvel reproduzir com exatido a simplicidade de um bolo de fub, o que dizer de software? Em 1986 Fred Brooks publicou o artigo "No Silver Bullet", que aparece como o captulo 16 na edio de 20 aniversrio de "The Mythical Man-Month". No texto ele previa que em um horizonte de 10 anos no apareceria nenhuma evoluo, nem tecnolgica nem gerencial, que promoveria ganhos considerveis de

47/60  47/60 

produtividade e confiabilidade. "Ceticismo no pessimismo", Brooks frisava. Nove anos depois, para a edio comemorativa, ele escreveu "'No Silver Bullet' Refired", seu 17 captulo. Responde algumas crticas e conclui que estava certo em sua avaliao. Uma avaliao que pode ser resumida em uma frase apenas: "Construir software ser sempre difcil". Brooks fundamenta sua tese apresentando quatro propriedades ("irredutveis") da 'entidade' software:
D Complexidade: uma propriedade essencial, no acidental. Ou seja, software uma entidade

complexa por natureza, "talvez a mais complexa de todas as construes humanas". De tal complexidade vem a dificuldade de comunicao 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 confiana. da complexidade da estrutura que vem a dificuldade de se criar novas funcionalidades que no resultem em efeitos colaterais indesejados. Em suma e para usar um termo bem nosso, tupiniquim: Software um bicho de sete cabeas. Ponto.
D Conformidade: "grande parte da complexidade que deve ser dominada pelo engenheiro de software

arbitrria, forada sem rima ou razo pelas diversas instituies humanas e outros sistemas os quais suas interfaces devem conformar. Isso muda de interface para interface, de tempos em tempos, no apenas porque h uma necessidade, mas porque as interfaces so desenhadas por pessoas diferentes".
D Instabilidade (de changeability): "A entidade software est constantemente sujeita a presses por

mudanas". "Software pode ser alterado facilmente - ele infinitamente malevel".

D Invisibilidade: abstraes geomtricas so muito teis, mas no conseguem representar toda a

complexidade de um software.

Brooks lista ento uma srie de avanos que podem ajudar a melhorar a qualidade de nossos projetos. Mas frisa que nenhum deles uma bala de prata: Linguagens de alto nvel (ele cita Ada - lembrem-se, o artigo

48/60  48/60 

 de 1986); Orientao a Objetos; Programao Automtica; Programao Grfica; etc. Na sequncia ele lista alguns princpios que podem atacar diretamente a essncia dos problemas com software:
D Comprar ao invs de Construir: "a soluo mais radical para os problemas com a construo de

software no constru-los". De certa forma as ondas ERP e CRM livraram vrias empresas de grande parte do peso da construo e manuteno de sistemas. Mas todas as organizaes ainda demandam solues especficas. Se no as constroem internamente, contratam servios de desenvolvimento. No acredito que um dia ser possvel comprar pacotes (ou componentes ou servios) para todo e qualquer tipo de problema de negcio.
D Refinamento dos Requisitos e Prototipao Rpida: "a parte mais difcil da construo de software

definir precisamente o que construir". "Creio que impossvel 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 verses". Portanto, segue Brooks, "um dos mais promissores avanos o desenvolvimento de mtodos e ferramentas para a prototipao rpida de sistemas como parte do processo iterativo de especificao dos requisitos".
D Desenvolvimento Incremental: aumente (cresa) um software, no construa (no texto original,

"grow, not build, software"). Para Brooks a metfora da construo j deu o que tinha que dar. "Vamor olhar para a natureza e estudar a complexidade dos seres vivos ao invs dos trabalhos 'mortos' do homem". Este princpio pode ser aplicado tanto no ciclo de vida do projeto quanto no ciclo de vida do prprio produto. Processos iterativos e incrementais j so comuns. Quase 'carne de vaca'. O que novo a forma como o Google, por exemplo, 'cresce' e evolui seus servios. No se trata meramente de uma manuteno, e eu acredito que muitos de nossos produtos podem ganhar com esse novo enfoque. Independente do pblico e da tecnologia, diga-se de passagem.
D Grandes Designers: "Grandes projetos (designs) vm de grandes arquitetos (designers). A construo

de software um processo criativo. Uma boa metodologia pode fortalecer e liberar uma mente criativa; mas no pode inflam-la ou inspir-la". Brooks conclui: "a principal questo para a evoluo da arte do software est centrada, como sempre esteve, nas Pessoas". No por acaso que Brooks encerra seu livro recomendando a leitura de "Peopleware" , de Tom DeMarco.

49/60  49/60 

Receitas, Metodologias, Processos...

E no parece ser uma mera coincidncia que Scott Berkun inicie seu livro citando... "Peopleware", de Tom DeMarco:

"A obsesso com metodologias outra instncia da iluso high-tech. Deriva da crena de que o que realmente importa a tecnologia... Independente de qual seja o avano tecnolgico, ele cobrar seu preo com a deteriorao 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 so promovidos por um respeitado guru". Berkun coloca que processos e metodologias so muito importantes, mas nunca sero 'balas de prata', entregadores de projetos bem sucedidos. E alerta para o perigo dos gerentes, em determinado momento de um projeto, "comearem a acreditar que o Processo o Projeto". Pode parecer absurdo, mas este desvio mais comum do que se imagina. Um bom processo, segundo Berkun, apia as pessoas e amplifica o seu valor. E seria o resultado da combinao 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.

50/60  50/60 

Eu gosto de acrescentar uma terceira varivel, to importante quanto o projeto em si e o time, no momento da seleo/customizao de um processo: o Cliente. Quando se trabalha na indstria, como o caso de Berkun, raramente se dispara um projeto para um cliente especfico. Da sua omisso. Mas no mercado de prestao de servios de desenvolvimento altamente recomendado que o perfil (valores e a cultura) do cliente seja levado em considerao no momento da customizao do processo. Em alguns casos o prprio cliente solicita a incorporao de alguns mtodos e artefatos, quando no a adoo de um ciclo de vida especfico. Mas o importante aqui entender que no existe e nem nunca existir uma 'metodologia mgica', aplicvel em vrios projetos. Cada projeto exigir um processo especfico. Mas isso no significa que a organizao sempre partir 'do zero'. Muito pelo contrrio. A primeira varivel 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 orgnico, j que o natural que ele cresa e fique mais rico a cada projeto. Infelizmente, quando olhamos algumas particularidades do mercado brasileiro de prestao de servios de desenvolvimento, percebemos que muitas empresas do pouqussimo valor para esse aprendizado, lanando mo de vnculos empregatcios muitos frgeis (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. No o meu caso. A explicitao de conhecimentos, sua compilao em artefatos que podem ser recuperados a qualquer momento, benfica para todas as organizaes. Mas no consegue representar nem um pequeno pedao de toda a experincia adquirida por um time durante a execuo de um projeto. Trata-se de outra 'iluso high-tech', para usar um termo do DeMarco.

51/60  51/60 

Voltando ao Berkun. Logo no incio de "The Art of Project Management" ele ensina trs 'lies-chave' que guiam boa parte de seus mtodos, guias e sugestes. So elas:
D Gerenciamento de Projetos e Desenvolvimento de Software no so artes sagradas: apesar do ar

de 'novidade' que impera em nossa rea, crucial lembrar que existem ensinamentos que podem vir de outros lugares.
D Quanto mais simples for a sua viso do que voc faz, mais poder e foco voc ter em sua

execuo: estar sempre curioso e aberto novas idias o que torna o crescimento possvel. Uma viso simples de nosso trabalho pode facilitar sua comparao com outras coisas que existem ao nosso redor. Aumentamos assim a possibilidade de aprendizagem.
D Simples no sinnimo de fcil: correr uma maratona simples, certo? Basta comear a correr e

no parar at alcanar o quadragsimo kilmetro. Voc diria que fcil? Liderana e gerenciamento tambm so difceis, mas sua natureza - realizar coisas de determinada maneira atrs de um objetivo especfico - simples. Bolos de fub e pes de queijo tambm so extremamente simples. No consigo entender porque s aqui em Minas eles so realmente gostosos.

52/60  52/60 

Eplogo
Encerro assim o artigo que elaborei com a inteno de homenagear Fred Brooks e sua obra prima, "The Mythical Man-Month", e tambm para apresentar o caula dos gurus (ele detestaria o rtulo), Scott Berkun. Como eu disse l no incio da viagem, estes artigos no substituem de forma alguma o prazer de ler os dois livros. E, posso garantir, no cobrem nem 10% de seu contedo. O retorno que eu recebi (infelizmente a maioria foi off-blog) compensou com sobras o trabalho. O prprio 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 no concordar com minha comparao, Scott me presenteou com uma cpia autografada de seu livro. Ah, se ele soubesse como toro para que seu livro no permanea atual daqui 25 anos. A longevidade do livro de Brooks indica, de certa forma, que no aprendemos muito. Ou que no aprendemos direito. Eu sinceramente gostaria que ambos se transformassem em relquias, documentos de um tempo em que a gente estava brincando de aprender a desenvolver software e a gerenciar projetos.

53/60  53/60 

O prximo passo, ensinou Brooks, aceitar que

"software um dos mais complexos trabalhos manuais do homem. Tal complexidade demanda nosso contnuo aprendizado, a melhor utilizao das novas ferramentas, uma melhor adaptao a mtodos gerenciais, a aplicao do bom senso e, acima de tudo, humildade para reconhecer nossas falhas e limitaes".

54/60  54/60 

Servio
The Mythical Man-Month
Frederick P. Brooks Jr Addison Wesley R$ 89,20 (Na Cultura, em 09/mar/06)

The Art of Project Management

Scott Berkun O'Reilly R$ 124,24 (Na Cultura, em 09/mar/06)

55/60  55/60 

Outras Obras Citadas

1. Software Engineering Economics Boehm, Barry Prentice-Hall, 1981. 2. Exploratory experimental studies comparing online and offline programming performance Sackman, H., W.J.Erikson, e E.E.Grant CACM, 1968. 3. Chief programmer teams, principles, and procedures Mills, H. IBM Federal Systems Division Report FSC 71-5108, 1971. 4. O Advento da Nova Organizao Drucker, Peter Harvard Business Review, 1991. Republicado em HBR Gesto do Conhecimento Editora Campus, 2001. 5. The New New Product Development Game Takeuchi, H. e I. Nonaka Harvard Business Review, 1986. 6. Peopleware Productive Projects and Teams DeMarco, Tom e Timothy Lister Dorset House, 1999 e 1987. 7. Criatividade e Grupos Criativos De Masi, Domenico Sextante, 2003. 8. Requirements-Led Project Management Robertson, Suzanne e James Robertson Addison-Wesley, 2003. 9. Programming System Dynamics Lehman, M. e L. Belady ACM SIGOPS, 1971.

56/60  56/60 

Crditos e Consideraes Finais

As imagens utilizadas neste artigo so de Chema Madoz, fotgrafo espanhol que no faz nenhuma questo de esconder sua maior influncia, 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". Alis, boa parte das fotos presentes no livro so do prprio Scott Berkun. Que faz uma coisa que nunca vi em livros tcnicos: 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, Rgis, Jos Papo, Ivo Michalick e outros amigos 'ocultos' deixaram sua contribuio, na forma de comentrios neste blog ou no grupo de discusso CMM-Brasil. Muito obrigado a todos. Guz Vasconcellos colaborou na reviso, com palpites de diagramao e nos momentos de descontrao, levando considerveis goleadas no Winning Eleven 8. That's all, Folks?

Claro que no. O finito seguir com um artigo por semana, sempre girando em torno dos temas Engenharia de Software, Gerenciamento de Projetos, Arquitetura de Solues, e tudo o mais que caiba neste 'torto' tringulo. Sugestes de temas? Quer trocar idias? Levar palestras e workshops para sua escola ou empresa? Demorou!

57/60  57/60 

Ops... err... Vc fez uma busca por 'bolo de fub' e caiu aqui por engano? Ou ento ficou morrendo de curiosidade? o seguinte: Ingredientes: 4 ovos 4 copos de leite 1 xcara e meia de acar 1 xcara 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 xcara de queijo (canastra ou parmeso) 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 acar, 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 frma untada e leve ao forno quente por mais ou menos trinta minutos. Se vai ficar bom como o da minha V eu no posso garantir. No existe receita mgica, certo?

58/60  58/60 

Trabalho liberado sob uma Licena Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil. Voc pode copi-lo e compartilh-lo vontade. Desde que no seja para fins comerciais, o que depende de uma liberao prvia do autor. Voc tambm pode alter-lo ou criar outros artigos ou documentos a partir dele. Mas lembre-se de compartilh-lo sob uma licena idntica. Ah, e de citar o(s) autor(es) tambm.

59/60  59/60 

O que o

finito?

O finito um conjunto de servios desenhado para atender organizaes que executam projetos, particularmente aqueles voltados para o desenvolvimento de software. Os servios foram estruturados na seguinte sequncia: D Inicio bem o projeto, com o p direito e o correto entendimento da dor que devo sanar; D Me comunico de maneira adequada, com todos e o tempo todo; D Sou flexvel e me adapto, entendo que cada projeto demanda um processo especfico; e D Vivo aprendendo, fao de cada projeto uma escola. Os servios podem ser contratados individualmente ou em grupos configurados pelo prprio cliente. Dentre os formatos de contratao disponveis, alm de consultoria, esto palestras, workshops e treinamentos. Para maiores informaes consulte este prospecto (pdf) ou entre em contato: finito@pfvasconcellos.eti.br. What needs to be done? uma questo formulada por Peter Drucker em uma entrevista para a revista Business 2.0. a Grande Pergunta que, segundo Drucker, todo executivo ou gerente deveria fazer todo dia.

60/60  60/60