PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • Agile Product Management with Scrum

    Autor: Roman Pichler é um especialista alemão em Scrum e gerenciamento Ágil de produtos. Este é seu primeiro livro em inglês. Anteriormente publicou “Agiles Projektmanagement erfolgreich einsetzen” (Scrum – Applying Agile Project Management Successfully) pela dpunkt.verlag, em 2008.

    Editora: Addison-Wesley | Mike Cohn Series (2010).

    Tema: Gerenciamento Ágil de produtos através do Scrum (dã!). É mais que isso: é o único livro que conheço dirigido especificamente para Product Owners (Donos de Produtos), o papel mais complexo e controverso em projetos guiados pelo framework Scrum.

    São no mínimo curiosas algumas contradições do Universo Ágil, particularmente aquele que defende e dissemina o uso do Scrum. Por muito tempo deram atenção quase exclusiva para a formação de ScrumMasters. Só agora começamos a ver a devida preocupação, através de cursos e deste livro, com aquele que de fato é o papel mais crítico e complexo em um projeto Scrum, o Product Owner (PO).

    A quem se destina: Todos que desempenham, sonham em desempenhar ou caíram de paraquedas no role (hole?) Product Owner.

    Dê de presente para:

    • Super-usuários e / ou especialistas destacados para o papel de PO;
    • Gerentes de Projetos;
    • Gerentes de Produtos;
    • Analistas de Negócios (principalmente se estiverem atuando em projetos guiados pelo Scrum).

    Contra-indicações: Só não é indicado para quem apresenta reações alérgicas ao termo Agile.

    Prós:

    • Texto objetivo (o livro tem só 133 páginas);
    • Bem ilustrado com exemplos e casos reais;
    • Não fica “em cima do muro” em alguns pontos polêmicos sobre o uso do Scrum. (Mais sobre isso abaixo).

    Contra:

    • O que é uma vantagem (a objetividade) pode ser percebida como superficialidade. Roman poderia ter explorado um pouco mais alguns pontos mais complexos, como a criação da Visão do Produto (capítulo 2, “Envisioning the Product”). Apelo para Fred Brooks¹ para justificar minha crítica: “A fase mais complexa e crítica de um projeto de software é aquela onde definimos o que precisa ser feito.” Na trilha de estudo, abaixo, apresento uma sugestão para preencher um certo ‘vazio’ deixado por Pichler.

    Cutucando Feridas (alguns trechos):

    • “Minha experiência sugere que um Product Owner não consegue cuidar de mais de dois times de maneira sustentável”. (pág. 12)
    • “A criação da Visão é melhor compreendida como um processo de descoberta, um processo de aquisição de conhecimento e aprendizagem que requer experimentação”. (pág. 37)
    • “O Scrum não dita como um requisito deve ser descrito”. (pág. 53)
    • “As atividades de manutenção e evolução²  da primeira iteração (sprint) tratam de itens da segunda iteração, e aquelas da segunda iteração têm como foco os item da terceira iteração, e assim por diante.” (pág. 60)
      Destaquei este trecho porque ele toca em um ponto que gera estranhos debates. Quem cuida do desenvolvimento de requisitos, seja o PO ou um analista de negócios, sempre estará pelo menos uma iteração à frente do restante do time. Pichler sugere que, dependendo dos riscos e incertezas acerca do projeto, o PO trabalhe com até três iterações de distância. O planejamento de cada iteração depende da existência de um conjunto de itens adequadamente entendido e detalhado.
    • “Product Owner e ScrumMaster não devem fazer estimativas nem influenciá-las”. (pág. 67)
    • “A fixação do prazo, orçamento e escopo não é possível; pelo menos uma das três restrições deve ser tratada como uma ‘válvula de escape’”. (pág. 76)
    • “Seu papel durante o planejamento de uma iteração é ajudar o time a entender o que precisa ser feito. O time decide quanto pode ser entregue e como será feito”. (destaques em itálico do autor, pág. 98)

    Trilha de Estudo:

    • Será simplificada desta vez: “Agile Project Management – Second Edition”, de Jim Highsmith (Addison-Wesley, 2010), é um complemento mais que necessário e natural para o livro do Pichler. Por isso será  a próxima entrada desta biblioteca, a ser publicada ainda nesta semana.

    Observações:

    1. No artigo “No Silver Bullet” (1987), republicado como capítulo adicional do clássico “The Mythical Man-Month” (“O Mítico Homem-Mês”, Campus, 2009).
    2. Utilizei os termos “manutenção e evolução” como tradução de “grooming”, termo amplamente utilizado por Pichler. Perdão, mas não consegui encontrar tradução mais adequada. Sugestões?

  • Morte e Vida UML

    Há exatamente um ano Ivar Jacobson “media a temperatura” da UML. Como um de seus criadores, Jacobson fez uma leitura honesta da moda (“espalhou como fogo em mato seco”), desilusão, críticas de acadêmicos e agilistas e do ressurgimento da UML. Concluiu pedindo um uso mais “esperto” (smart) da linguagem. Conclusão vaga e marketeira: ele mantém o “Smart Blog” que vende um “Smarter Way”. Muito smart e ambíguo para o meu gosto.

    O que não desvaloriza seu diagnóstico objetivo e claro do momento atual da UML. Sim, a UML ganha uma segunda vida. Ou deveríamos dizer segunda chance? Até a Microsoft, que parecia ter sugerido de forma um tanto ingênua que DSL’s (Domain-Specific Languages) seriam alternativas à UML, agora destaca seu amplo suporte como um diferencial da nova versão do Visual Studio¹. São diversos os sinais que indicam um tipo de renascimento da UML. O que fazer para evitar um novo ciclo de desilusões e abandono?

    Deveríamos começar por uma isenta avaliação de tudo o que fizemos de errado na primeira onda. Em primeiro lugar há nossa irritante mania de viver colocando a carroça na frente dos bois. A adoção da UML significou, para várias organizações, a aquisição de ferramentas caríssimas. Os fornecedores dessas ferramentas, cumprindo bem o seu papel, prometiam maravilhas. Particularmente em relação ao aumento da produtividade dos desenvolvedores. Ignoravam ou faziam vista grossa para um contexto mais amplo. A incorporação da UML normalmente fazia parte de um plano maior: a implantação de novos métodos de trabalho. Numa cumbuca mais sortida que feijoada baiana fica difícil apontar responsáveis diretos por ganhos ou perdas. E a UML acabou pagando muito mais do que devia. Tanto que até hoje encontramos pessoas que acham que UML é uma “metodologia”.

    Ensinar UML através de uma ferramenta é como ensinar matemática com calculadoras: um grande e sério erro.

    Desconfio que a raiz do problema está na forma como UML é ensinada e aprendida. O ensino da UML através de uma ferramenta, qualquer ferramenta, é um grande erro. Tão sério quanto ensinar matemática com calculadoras. Os alunos não têm a chance de perceber a UML como ela é, como uma Linguagem. E as limitações das ferramentas, que não são poucas, acabam interpretadas como limitações da linguagem.

    Por exemplo, não é raro encontrar pessoas que dizem que o desenho ao lado é um erro. Para elas a UML seria um simples padrão de notação. E, como tal, estaria restrita às figurinhas oferecidas nas ferramentas. Considero este o mais sério e comprometedor problema que temos com a UML. Uma limitação que nos leva a utilizá-la da mesma maneira que um compositor de funk carioca utiliza a língua portuguesa.

    Como toda linguagem, do português ao C#, a UML é viva. É extensível. Podemos e devemos adaptá-la às nossas necessidades. Mas fizemos um serviço tão ruim neste ponto que existem aqueles que acham que a possibilidade de criar extensões como a EPBE (Eriksson-Penker Business Extensions) é gambiarra ou correção de bugs, não uma característica projetada da linguagem.

    Ao ensinar UML devemos abandonar toda e qualquer ferramenta automatizada. Lápis e páginas de caderno são tudo o que precisamos para ensinar e aprender UML. Um profissional que domine bem os conceitos da linguagem saberá tirar mais valor de qualquer ferramenta que lhe seja oferecida. E assim, talvez, aquelas promessas maravilhosas dos fornecedores de ferramentas se realizem.

    Grande Demais, Complexa pra Chuchu

    Não deveríamos ensinar português através da gramática e sim com Chico Buarque e Machado de Assis.

    São outras críticas comuns, que aparecem principalmente no discurso de alguns agilistas. Toda linguagem é naturalmente complexa. Ou, melhor colocando: toda gramática², em sua plenitude, é naturalmente complexa. O fato é que pouquíssimos de nós dominamos a gramática da língua portuguesa, por exemplo. Mas isso não impede que utilizemos a língua das mais diversas maneiras em nosso dia a dia. O mesmo precisa ser dito sobre a UML. Ninguém precisa conhecer de cor e salteado toda a especificação e o metamodelo da UML, sua gramática, para poder utilizá-la. Aliás, se quisermos espantar fregueses, basta apresentar a UML desta forma.

    A UML é grande por necessidade, não por pura encheção de linguiça. E parece complexa para todos que não entendem ou não aceitam sua proposição original, de ser uma Linguagem Unificada de Modelagem. Ela é perfeita? Claro que não – fomos nós humanos que a criamos. É boa? Sim, eu diria excelente. Mas talvez esteja aqui seu grande problema: não há nada que possa ser comparado à UML. Lá em meados dos anos 90 tínhamos dezenas de propostas de padrões de notação. A UML veio para acabar com aquela baderna. Mas seu sucesso e consequente aceitação universal – um tipo de monopólio – criou este problema. Ela não é pior nem melhor nem maior nem mais complexa que ninguém simplesmente porque não temos com o que comparar.

    UML não é Chacrinha

    O Chacrinha dizia que tinha vindo para “complicar, não para explicar”. O maior objetivo da UML é o oposto. E, de novo, tenho que apelar para o “L” de UML: toda linguagem criada pelo homem tem esse único objetivo, facilitar a comunicação. Mas não são poucas as organizações que destruíram esse propósito quando instituíram que UML era “padrão de documentação”. Quando passaram a exigir que esse ou aquele diagrama fossem elaborados com o único propósito de documentar determinado trecho de um projeto. Nada pode ser mais nocivo e criar mais antipatia a uma proposta do que a percepção de obrigatoriedade descerebrada ou insensata. Por isso não são poucos os que fazem cara de nojo quando ouvem as letrinhas U-M-L. Passa da hora de devolvermos à UML suas proposições originais: explicar, e não complicar; Facilitar a comunicação e interação, e não substituí-las.

    Confesso que a ficha do péssimo uso que fazemos da UML só caiu quando comecei a participar de alguns fóruns e a apresentar meus eventos para analistas de negócios. Cheguei a acreditar na realização da profecia sugerida na capa da Software Development de abril de 2001, apresentada acima. Mas aí vieram o artigo do Jacobson, debates mais ricos, empresas interessadas na ressurreição da UML e a onda do Pensamento Visual. Taí, a UML realmente tem sua segunda chance. Ou eu deveria dizer que nós temos uma segunda chance?

    .:.

    Observações:

    1. Na revista INFO de junho/2010 tem um anúncio do Visual Studio, apresentado na forma de uma entrevista com o gerente de produtos da Microsoft Brasil, Sr. Rodrigo de Carvalho. A primeira pergunta é: “Por que clientes devem migrar para a nova versão do Visual Studio 2010?”. Resposta: “Por várias razões, mas destacaria: suporte à modelagem UML…“. Sim, ele começou pelo suporte à UML. Quem conhece o histórico das idas e vindas da MS em relação à UML entenderá o meu destaque aqui.
    2. Gramática, segundo o Houaiss, é um “conjunto de regras que determinam o uso correto de uma língua”.
      Não exagero quando trato a especificação da UML como um tipo de gramática. E reitero objetivando a aceitação de que UML é de fato uma língua. E que, como tal, ela deve nos ajudar a atender três grandes objetivos: i) Organizar o conhecimento; ii) Representar o conhecimento; e iii) Trocar conhecimentos.

  • finito: ano 6

    Hoje o finito completa 6 anos de vida. Parece que foi ontem que o iniciei, ainda no Blogspot, para registrar um trabalho sobre gestão de conhecimentos interprojetos. Naquele tempo não imaginava que ele se tornaria minha plataforma e vitrine.

    Não é coincidência o fato dele fazer aniversário no mesmo mês que comemoro o início de minha vida profissional. Completei, no dia primeiro (!), 24 anos de estrada. Desde o pré-histórico 1986 maio tem sido um mês especial. É o meu janeiro.

    Mês de reflexões e resoluções, além de uma agenda quase caótica. Por isso a festinha só vai rolar na quinta-feira, ao som de ZZ Top, em Sampa.

    É a primeira vez que faço esse tipo de registro aqui. Pode ser porque ele represente um milestone. Ou até uma virada, quem sabe? Inté!

    .:.

    “Squares and Dots“, a foto utilizada neste post, é de 1Happysnapper.

  • The Back of the Napkin

    Autor: Dan Roam é presidente da Digital Roam Inc., empresa que consultoria que já atendeu clientes como Google, eBay, GE, Boeing e Wal-Mart. Seu método já foi apresentado no Senado dos EUA e em canais de TV como CNN, MSNBC e Fox News, dentre outros.

    Editora: Portfolio (EUA, 2008).

    Do que se Trata: “Resolver problemas e vender ideias com figuras” (subtítulo do livro). Roam apresenta o Pensamento Visual, um método que se baseia na seguinte premissa: uma imagem vale mais que mil palavras. Aprendemos aqui que a imagem certa vale bem mais que mil palavras.

    A quem se destina: Todo mundo que resolva problemas e / ou venda ideias.

    Dê de presente para:

    • Analistas de Negócios e de Sistemas
    • Líderes de Projetos
    • Desenvolvedores
    • Executivos
    • Seu colega que fala e / ou escreve demais.

    Contra-indicações: Nenhuma. E Roam prova que todo mundo pode aprender a desenhar.

    Prós:

    • Leitura fácil e muito agradável.
    • Roam é muito didático. E os exemplos utilizados são bons.
    • A diagramação esperta evita idas e vindas.

    Contras:

    • A base da neurobiologia, relevante que é, não deveria estar no apêndice. O autor nos convida a visitá-lo várias vezes no início do livro. Aceite o convite.
    • Os exemplos são bons mas poucos. Por isso o autor se apressou em lançar um complemento, “Unfolding the Napkin” (mais sobre ele abaixo).
    • Quem já tem o costume de desenhar para entender ou explicar pode achar o livro meio “basicão”. Mas, inexplicavelmente, anda raro encontrar pessoas com tal hábito. Mais difícil ainda é encontrar quem o faça de maneira sistemática, amparado por um método consistente.

    Apresentação / Complementos:

    Trilha de Estudo:

    1. Obrigado pela Informação que Você NÃO me Deu!
      Normann Kestenbaum – Campus / Elsevier (2008).
      Apresentado anteriormente na biblioteca do finito.
    2. Unfolding the Napkin
      Dan Roam – Portfolio (2009).
      Um método “hands-on” – um workshop de 4 dias com vários exemplos e exercícios. Complemento obrigatório de “The Back of the Napkin”.
    3. Business Modeling with UML
      Hans-Erik Eriksson e Magnus Penker – Wiley (2000).
      Aqui pisamos em solo pedregoso. Livro indicado apenas para quem quer megulhar de cabeça no uso da UML para a modelagem de negócios. Para analistas de negócios, considero um caminho inevitável. É interessante notar que, a exemplo do que acontece no FAN, o método de Dan Roam facilita bastante esta viagem. Dois artigos de minha autoria mostram um pouco deste ‘casamento’:
      Modelagem de Negócios: Uma Sugestão
      Modelagem de Negócios: Os Diagramas
    4. Business Modeling – A Practical Guide to Realizing Business Value
      David M. Bridgeland e Ron Zahavi. Morgan-Kaufmann (2009).
      Citado anteriormente por aqui. Não concordo nem um pouquinho com as sugestões dos dois autores: 4 linguagens ou padrões de notação diferentes para cada aspecto do negócio (BPMN se encaixa aqui). Prefiro o uso de uma única língua, UML. Mas preciso dizer que é um caminho alternativo para analistas de negócios e afins.

    .:.

    PS: Eu prometi uma trilha por mês. E falhei em abril. Portanto, aguardem outra entrada em nossa Biblioteca ainda em maio.

  • Iterativo & Incremental: O Segundo Fator

    Semana passada sugeri uma forma alternativa de apresentar e justificar a adoção de um ciclo de vida para projetos baseado no modelo Iterativo & Incremental. Deveríamos enfatizar a certeza de que todos cometerão erros em detrimento do destaque dado às inevitáveis mudanças.

    Faltou dizer que muito do que chamamos de mudanças são na realidade erros. Usuários e clientes não são obrigados a aprovar o primeiro produto que recebem, por precisas e assinadas que sejam atas, especificações de casos de uso ou afins. Há mais mistérios entre requisitos e o produto final do que imagina nossa vã filosofia. E essa distância sempre exigirá, em alguma medida, um processo de tentativa e erro. Esse tipo de mudança é sim um erro. Muitos não gostam da palavrinha ou de admitir que erram. Mas deveríamos classificar melhor aquilo que chamamos de erros e mudanças. Papo para outra hora.

    Porque hoje eu gostaria de destacar um segundo fator que justifica a adoção do modelo Iterativo & Incremental: as pequenas vitórias. Assim como é indiscutível que o ser humano erra, também é indissociável de nossa natureza a necessidade de motivação – de uma recarga quase diária de nossas baterias. Em projetos não bastam seus objetivos, por nobres e ambiciosos que sejam, nem eventuais compensações financeiras. Imagine um campeonato de futebol, curto como uma Copa do Mundo ou longo (e cansativo) como o Brasileirão. Os times e jogadores comemoram cada vitória e cada gol. No vôlei, um jogo definido após dezenas de pontos, cada um deles é comemorado. Cada gol ou ponto é uma pequena vitória. Elas são tão cruciais para uma equipe de projetos como são para os jogadores.

    Em projetos tocados segundo moldes convencionais, particularmente no popular “cascata”, há pouco espaço para comemorações intermediárias. Por mais que equipe e coordenadores soltem foguetes para um documento de visão bem escrito ou uma coleção de especificações e modelos “nota 10”, o fato é que não há torcida nem usuários ou clientes compartilhando aquele momento e muito menos incentivando-o. É como uma vitória em treino, fechada e sem valor.

    A vitória que conta, por menor que seja, tem participação direta do público externo – dos usuários e clientes. E eles sabem que documentos e modelos não valem como gols e pontos. Ou seja, não substituem o produto final.

    Um projeto guiado pelo modelo Iterativo & Incremental supõe a comemoração de várias pequenas vitórias. Admite sim alguns revezes, como vimos no artigo anterior. Mas, exatamente por conta deste fator, torna a vitória final mais factível. Cada entrega, iteração ou gol é motivo para celebração. E isso ajuda a renovar o ânimo do time. No contexto de projetos há outros efeitos colaterais bastante benéficos, sendo o principal deles o aprendizado. O time tem a chance de rever seus erros e acertos, o que possibilita uma melhor preparação do próximo ataque, jogo ou iteração.

    Imagine um zero a zero arrastado e chato. Pior ainda, decidido nos pênaltis. Compare com uma sonora goleada, um jogo aberto e bonito de se ver, com placar final de 5 a 3. Qual você prefere?

    .:.

    “Goal“, a foto utilizada neste artigo, é do Jonas B.

  • Iterativo & Incremental: Um Convite aos Erros

    Entre todos os mistérios que rondam nossa área há um difícil de explicar e justificar: qual a razão de tanta resistência na adoção de um ciclo de desenvolvimento que seja iterativo e incremental?

    Nos últimos três anos, só por conta do FAN, pude falar com mais de dois mil profissionais e estive pessoalmente em dezenas de empresas. Sei que não tem valor de pesquisa, mas foi fácil concluir que pelo menos 95% deles ainda trabalham baseados em um modelo “cascata” (ou Waterfall) de desenvolvimento¹. Se considerarmos que já tem quase duas décadas que vários autores, metodologistas, empresas e consultores recomendam a adoção de outro modelo, qual a razão da incontestável predominância da “cascata”?

    Não, este (pequeno) artigo não tem a menor intenção de reativar o debate ou destacar prós e contras de cada proposta. Aliás, se você quiser uma boa justificativa *econômica* para adoção do modelo iterativo & incremental, deveria ler este texto do José Paulo Papo. Minha preocupação aqui é outra.

    Comumente apresentamos o modelo iterativo e incremental, independentemente do sabor (RUP, XP, Scrum, OpenUP…), como um remédio para as inevitáveis mudanças. Esse discurso costuma encontrar dois tipos de reflexos:

    1. (Ainda) existem aqueles que acreditam que mudanças ocorrem exclusivamente porque o entendimento do problema não foi bem realizado. São os mesmos que, infelizmente, acreditam que a Análise de Negócios é a resposta definitiva para especificações (sic) mal feitas. O que vemos neste cenário é mais gente gastando mais tempo e dinheiro para escrever mais. Deveríamos escrever melhor, estruturar melhor as informações aprendidas e colaborar, conversar mais. E não escrever mais e de maneira mais detalhada².
    2. “Os requisitos são estáveis e temos uma ótima compreensão do problema que iremos sanar. Podemos trabalhar em ‘cascata’”. É um reflexo parecido com o anterior mas com uma diferença: há realmente a sensação de que o solo pisado é de fato conhecido. Esta é uma das justificativas que encontro com maior frequência para a não adoção de um modelo iterativo e incremental.

    Percebendo os dois reflexos alterei minha maneira de apresentar e “vender” o modelo iterativo e incremental. Transcrevo abaixo o que costumo falar nos treinamentos e consultorias:

    O que é bonito no modelo iterativo & incremental é que ele reconhece um fato que nunca mudaremos: somos humanos. Ou seja, nós vamos cometer erros. Vários! Ao adotar este modelo estamos dizendo para nossos usuários e clientes: “Nós vamos errar, caríssimos, todos nós. Às vezes será um problema de interpretação de seus requisitos e histórias. Outras tantas vocês errarão, na explicação ou apresentação das próprias necessidades. E, precisamos admitir, muitas vezes as funcionalidades entregues não os atenderão pelos mais diversos motivos. Não importa. Aliás, não importa desde que o modelo de desenvolvimento adotado reconheça essa verdade: somos humanos e vamos errar”.

    Esse discurso gera duas respostas muito positivas: i) desarma aqueles que ficam louquinhos por um debate; ii) facilita a compreensão por todos que nunca trabalharam de outra maneira que não seja a “cascata” ou o “caos absoluto”. São bastante perceptíveis também as carinhas de surpresa que surgem com a repetição de uma palavrinha: Erro.

    Criamos uma cultura que combate e pune erros. Mesmo em ambientes que se dizem “inovadores” o erro ainda é mal visto. As pessoas vivem com medo de errar. Imagine então o desafio de dizer, antes mesmo do início de um projeto, que erros acontecerão. Mas é fato: erramos. Pra caramba!

    Clientes e usuários costumam gostar muito dessa transparência, dessa sinceridade. Estranham porque ela não é muito comum em nosso mercado. Mas aceitam o modelo e o consequente desafio com mais facilidade³. Daqui para a adoção de outras práticas mais modernas é “um tirinho”.

    .:.

    Observações:

    1. Num belo dia um cliente pediu que eu pulasse essa parte do curso: “A gente já desenvolve assim”. Obedeci. Mas depois o treinamento caminhou na base de soluços. Descobri o problema e o susto que curou o soluço: “É que nossas iterações duram algo entre 3 e 4 meses”. Ou seja, eles não desenvolviam de forma iterativa e incremental. Era outra coisa.
      Um outro freguês, agora numa turma aberta, disse que usa Scrum mas que tem que levantar todos os requisitos no início do projeto. Ou seja, não era Scrum. Também era outra coisa qualquer que nem merece nome.
    2. Era uma vez uma empresa que terceirizava todo o trampo de codificação para “fábricas de software” (sic). Eu apresentava para eles os 5 ícones recomendados pelo Cockburn (“Escrevendo Casos de Uso Eficazes”, Bookman. 2006) para indicar o nível de detalhamento de uma especificação de caso de uso. Eles disseram que, para trabalhar com fábricas, os 5 não seriam suficientes. Pediram a criação de outro, abaixo da “ostra”. Sugeriram a colocação da logomarca da Petrobras. E explicaram: “É o nível ‘pré-sal’, sete mil metros abaixo do nível do mar! Só assim o pessoal da fábrica entende.” Repito: não é escrever mais. Não deveria ser…
    3. Era outra vez, lá pelos idos de 2001 ou 2002, eu tocava um projetão. ÃO mesmo, em porte e complexidade. Sabe-se lá porque ($$$) topamos que o cliente “espelhasse” toda nossa estrutura gerencial. Para cada líder de nosso lado, eles colocavam um líder do lado de lá. Um mês de lua-de-mel. Um mês de “briguinhas”. E no terceiro mês a pérola: “Para com esse negócio de iterativo e incremental – queremos que seja cascata”.
      Juro, não é cascata não. Contei a história aqui só para dizer que a palavra “facilidade”, escrita ali no último parágrafo, deve ser interpretada com a devida precaução.
    4. “Funny“, a foto utilizada acima, é da Tanakawho. Sempre ela!

  • Ora (direis) Gerir Estrelas

    “Certo perdeste o senso!”

    Perdão Bilac, mas não resisti. Não é a primeira vez que surrupio belas obras com fins questionáveis. Certo não será a última. A espoleta da vez não veio de TI, mas de um mundo tão distante quanto Pandora está da Terra: veio da bola, do pé na bola, do futebol. É a Copa que se aproxima. Mas não deveria ser. O futebol é algo tão rico de ensinamentos que merecia outro status e mais presença. Pena, ele segue em outra direção. E acaba de perder um de seus melhores tradutores, Sr. Armando Nogueira. Pena. Mas voltemos ao princípio: “Ora (direis) Gerir Estrelas!”

    “Certo perdeste o senso!” Porque, se há algo difícil de gerenciar, é a tal da estrela. Dá de mil e um no pior dos piores projetos. Dá de mil e dois no pior dos piores fregueses. Estrela, como o Flamengo está aprendendo da pior maneira, está sempre acima da gerência. Não apenas na grana depositada mensalmente, mas em praticamente tudo.

    É certo que estrelas de verdade brilham. Adriano foi o artilheiro do último campeonato brasileiro. Sem ele provavelmente o Hexacampeonato não teria acontecido. Em outra nação, a Corinthiana, Ronaldo decidiu, no primeiro semestre de 2009, uma série de partidas importantes. Sem ele o Timão não teria conquistado dois campeonatos. Benefícios assim costumam fazer com que os custos sejam tratados como pequenos detalhes, bobeirinhas. Perdão, mas são pouquíssimos no mundo que podem tratar um milhão de qualquer coisa por mês como um pequeno detalhe. No Brasil, talvez o Batista e mais dois. E olhe lá!

    O custo (exorbitante) de uma estrela é fixo. Seus resultados variam mais que bolsa de valores em tempos de crise. O que permite concluir que, em médio e longo prazos, uma estrela nunca se paga. Ok, “nunca diga nunca”. Então fechamos com “quase nunca se paga”.

    Defina “Estrela”

    Estrela é o craque, o expert, o bambambam em determinada área do conhecimento. Domina como poucos sua arte. Quando brilha, o faz de forma tão intensa que cega, maravilha e entorpece.

    Se a definição se limitasse ao que foi escrito acima este artigo não teria razão de existir. Acontece que uma estrela é apaixonada pelo próprio umbigo. Se acha tão acima dos normais que acaba criando um universo só seu. Heliocêntrico, é claro. Tem seus próprios processos e regras. Seus próprios horários e calendários. E ai de quem discordar.

    Talvez só o futebol rivalize com TI no número de pessoas que recebem, de forma pejorativa ou não, apelidos como “deus”, “rei”, “gênio”, “monstro”, “fenômeno” etc. Mas há ESTRELAS e estrelas. Existem as anãs e as pagãs, as supernovas e os buracos negros. Supernovas, por exemplo, berram por “autogerenciamento” mas não conseguem botar ordem na própria mesa. Já os buracos negros sugam toda a energia (e recursos) ao seu redor – são mal humorados de nascença – e costumam sumir antes que algum resultado seja entregue.

    Em comum todos os (nossos) tipos de estrelas só apresentam dois fatores: i) normalmente são realmente bons no que fazem;  mas, ii) são difíceis, chatos, desagradáveis etc etc etc.

    Seu Projeto depende de uma Estrela?

    Meus pêsames. Ops… perdão. Não são raros, particularmente numa área tão nova, dinâmica e mal formada como TI, projetos que dependam muito da atuação de um craque. E é importante notar que nem todo craque é estrela. É claro que existem os humildes e mortais – que se caracterizam principalmente pelo tanto que são cientes de suas próprias limitações. Traduzindo: craques sabem dizer “NÃO”, “NÃO SEI” e também nunca apresentam estimativas absolutas. Mas você não deu a sorte de contratar um craque. Tens uma estrela em suas mãos. E agora?

    Só tenho duas dicas:

    1. Não crie a ilusão de um relacionamento duradouro. Contrate a estrela especificamente para um projeto. E faça girar em torno dela um ou dois planetas (funcionários de sua confiança) que tenham: i) estômago forte; ii) vontade de aprender.
    2. Vincule todo e qualquer pagamento à entrega de resultados. Faça com que a estrela se comprometa realmente com o sucesso do projeto. Desconheço outra maneira que não seja através do zelo extremo com os desembolsos e reembolsos.

    Seu Gerente é a Estrela?

    Hmmm… Mas que situação, hem? Não prestou atenção na hora da entrevista não? Ok, pode não ser o fim do mundo. Considere uma das alternativas abaixo:

    1. Trocar de emprego;
    2. Tomar o lugar do gerente;
    3. Ajudar alguém (gente boa) a tomar o lugar do gerente;
    4. Convencer o gerente que ele será mais importante, mais bem visto, mais sexy e bem sucedido se começar a trabalhar para a equipe, esquecendo o comportamento “comando & controle” e aprendendo que a “delegação de poderes” o fortalece e não o contrário. Pode garantir que, se ele aceitar tudo isso, será convidado para todos os happy-hours e churrascos da turma.

    Você é a Estrela?

    Desculpa aí. Não é nada pessoal não, viu gente fina?

    Inté!

    .:.

    Slinky Abstract, a foto utilizada este artigo, é de Paul Stevenson.

  • REWORK

    Autores: Jason Fried e David Heinemeier Hansson, fundadores da 37signals, empresa que fornece soluções para gerenciamento de projetos, colaboração, CRM dentre outras.

    Editora: Crown Business (2010).

    Do que se trata: Negócios de uma maneira geral. Mas pertence à nobre categoria “Tapa na Cara”. Um safanão em todos que continuam fazendo negócios no século XXI com mentalidade de século XIX.

    A quem se destina: Todo mundo, mas principalmente para quem tem ou pensa em ter seu próprio negócio.

    Dê de presente para:

    • Você, micro, pequeno, médio ou grande empresário
    • Seu sócio “conservador” ou “medroso”
    • Seu patrão “conservador” ou “medroso”. Neste caso, recomenda-se que o presente seja anônimo. E permaneça assim até que o chefão manifeste suas impressões sobre a obra.

    Contra-indicações:

    • Se o leitor for ultraconservador (bitolado), o livro será arremessado para bem longe. Mantenha uma distância segura.
    • Entusiasmados podem gerar uma tsunami de mudanças (todas sugeridas no livro) que não conseguirão administrar. O livro não tem posologia, mas use-o com moderação. Particularmente se você e sua empresa estão muito distantes do que é sugerido ali.

    Prós:

    • Leitura agradável e fácil.
    • Buzzwords e modismos só aparecem para ilustrar seu próprio lado nefasto e bobo.
    • Não é todo livro de negócio que usa termos como “fuck” e “shit” com tanta naturalidade.
    • Eddie Van Halen e John Bonham (Led Zeppelin) não são referências tradicionais em livros de negócios (tradicionais).

    Contras:

    • Perdão, mas sigo no entusiamo de uma leitura recém-terminada. Ainda não consigo apontar nenhum “contra”.

    Alguns Trechos:

    Todas empresas têm clientes. As sortudas têm fãs. Mas as mais felizardas têm uma audiência. E audiência pode ser sua arma secreta.
    …
    Ao invés de correr atrás de pessoas, você quer que as pessoas venham atrás de você. Uma audiência sempre retorna – por vontade própria – para saber o que você tem a dizer. E este é o mais receptivo grupo de clientes ou clientes potenciais que você vai ter.
    …
    Se eles gostarem do que você tem a dizer, muito provavelmente gostarão também do que você tem a vender.
    …
    Quando você constrói uma audiência, não tem que pagar pela atenção dela – ela a dá para você. E isso é uma baita vantagem.

    Os trechos acima foram surrupiados do subcapítulo “Build an Audience” (pág. 170). Estou publicando outros 37 no Twitter, com a tag #REwork.

    Inspiração:

    É interessantíssima a lista de pessoas que mereceram um “thank you” no final do livro: Frank Lloyd Wright, Warren Buffett, Steve Jobs, Kent Beck, Seth Godin, Jeff Bezos, Thomas Jefferson e Kathy Sierra, dentre outros. E pinta ali um brasileiro, Ricardo Semler, empresário e autor de alguns livros que, com certeza, inspiraram a dupla da 37signals.

    Obras Relacionadas:

    Hoje não vou apontar uma trilha. Poderia citar alguns textos do Seth Godin e do Guy Kawasaki, por exemplo. Mas trocarei as indicações por algo que pretendo fazer: ler “REWORK” de novo. O livro é curto (279 páginas, sendo que dezenas são apenas imagens que abrem os capítulos e subcapítulos) e merece algumas REleituras.

    Enquanto você aguarda a entrega do seu, leia um resumo publicado na forma de um manifesto no ChangeThis. E, claro, não deixe de seguir o blog dos caras, Signal vs. Noise.

    ps: O preço de capa é US$ 22. Mas na Amazon consegui o meu (novo) por apenas US$ 12. Uma pechincha que se paga em segundos.

  • FAN – Ano III

    Como foi antecipado, a estreia do novo formato do FAN acontecerá neste final de semana, em São Paulo. Além do conteúdo programático, mexi também na estrutura do treinamento e no visual do material de apoio. Destaco neste artigo as principais modificações e as justificativas para elas.

    O programa para Formação de Analistas de Negócios é um eterno trabalho em desenvolvimento. Aliás, eu acho que todo programa de treinamento é ou deveria ser assim. Sempre encontraremos algo que pode ou precisa ser melhorado. Durante os dois primeiros anos o conteúdo foi diferente em todas as turmas, para desespero do pessoal que confecciona as apostilas. A primeira grande alteração se deu após a quinta edição, quando dobramos a carga horária. A principal reclamação que recebíamos via fichas de avaliação era: “Puxa, a gente gostaria de exercitar suas sugestões”. Esticamos a duração do treinamento para poder incluir os módulos práticos.

    Alteramos também o material didático. Além das apostilas, os alunos também recebiam material de apoio para execução dos exercícios. Não bloquinhos de rascunho, como de costume, mas modelos que, apesar de extremamente simples, apoiavam o aprendizado ao reforçar os conceitos apresentados.

    Depois veio “The Back of the Napkin”, de Dan Roam (Portfolio, 2008), e com ele um novo método para o trabalho de modelagem de negócios. O núcleo das sugestões, baseado no uso da UML e sua extensão EPBE (Eriksson-Penker Business Extensions), foi mantido. Mas o método do pensamento visual facilitou tanto o aprendizado quanto a aplicação prática e imediata da modelagem de negócios.

    Só em agosto de 2009 eu resolvi “congelar” o conteúdo do FAN. Queria testar sua estabilidade em turmas abertas e fechadas. O “descanso” e relativo distanciamento do material foi proveitoso. Há pouco mais de um mês, quando o reencontrei, sabia exatamente o que alterar.

    A sequência do treinamento é madura, está bem resolvida. Mas slides envelhecem! Cerca de 70% dos slides têm a idade do FAN! De tanto apresentar o material, sempre com alguma variação, aprendi uma separação mais adequada entre o que vai na apresentação e o que é falado. É uma reengenharia gostosa de fazer, cheia de surpresas. Tem momentos em que 5 slides vão para o lixo. No momento seguinte, 7 novos slides berram para ver a luz. Ou seja, o tamanho da apresentação utilizada seguirá parecido: imenso.

    Aproveitei o esforço para “dar um tapa” no visual do material didático. Se os slides já eram minimalistas pra caramba, agora eles ficaram mini-minimalistas. Influência viciante de duas obras: “Presentation Zen”, de Garr Reynolds (New Rider Press, 2008) e “The Presentation Secrets of Steve Jobs”, de Carmine Gallo (McGraw-Hill, 2010). Treinamentos como o FAN são muito cansativos. Dois dias inteiros consecutivos fazem com que os alunos percam muita coisa, principalmente ao final dos dois dias. E a gente sabe que bullets, cores, efeitos e muita ladainha escrita e falada cansam. É claro que um treinamento assim tem muito pouco em comum com os imbatíveis keynotes do Steve Jobs, por exemplo. Mesmo assim, as duas obras citadas ajudaram a desenvolver um material de apoio que: i) Cansa menos; ii) Registra aquilo que é estritamente fundamental; iii) É de fato *Visual*; e iv) Foge das perigosas e feias armadilhas do Powerpoint e afins. Estou muito satisfeito com o produto final. Tanto que em breve, finalmente (!), vou liberar uma versão light na área de downloads deste site e também no Slideshare. Só peço que aguardem um pouquinho, até a conclusão do teste de verdade que farei neste final de semana.

    A distribuição dos exercícios também ajuda a tornar o evento mais produtivo e agradável. Distribuídos de maneira homogênea e com duração fixa, eles acabam ditando um ritmo. Sim, tô surrupiando aqui uma prática muito eficaz dos projetos guiados por métodos ágeis. O ritmo constante, estou apostando, deve tornar os exercícios ainda mais produtivos e eficazes. E, de quebra, os alunos mergulharão um pouco mais no modelo iterativo e incremental de desenvolvimento. As versões anteriores do FAN também tinham essa intenção. Mas existiam módulos muito extensos de teoria, seguidos de dois ou três exercícios consecutivos. Consegui encontrar um formato mais equilibrado. E sem nenhum prejuízo para a parte teórica. Ok, chega de blablablá. Que venham os testadores! Inté.

    .:.

    “Pô Paulo, que sacanagem! Se você tivesse avisado a gente teria aguardado essa nova versão…”

    Pessoal, a AUI! (angústia pelos upgrades infinitos) veio para ficar. Você acaba de gastar aquela bela grana num celular novinho e daqui a uma semana  aparecerá um melhor e mais feito pra ti. Será sempre assim. No caso fo FAN não se preocupem porque: i) Todo o material estará disponível para vocês, através de nosso grupo AN.br; e, ii) Estou programando dois eventos de atualização que serão disponibilizados para todos os 2.000+ participantes das turmas anteriores do FAN. Um deles será “na faixa”, “vasco”, “grátis”. Aguardem!

  • Motivação, Parte 2

    Se você perdeu, a parte 1 está aqui.

    Hoje vou falar sobre motivação em projetos “custom”, aqueles desenvolvidos especificamente para uma organização. O entendimento da motivação para esse tipo de projeto é um pouquinho mais complicado. Em artigos anteriores (1 e 2) eu falei sobre alienação (da equipe de desenvolvimento) e problemas de comunicação. A *motivação* desta série é a dificuldade que equipes apresentam para decidir o que é prioritário em um projeto. A *tese* aqui defendida é que todas as decisões sobre priorização deveriam se basear nos requisitos do negócio – nos objetivos que *motivaram* o projeto. Parece papo de maluco, né? Afinal, não é natural ou óbvio que seja assim? Envergonhadamente devemos admitir que não, não é natural.

    Chegamos em um estágio em que o usuário pede, “faz uma tela assim e assado”, e a equipe vai lá e faz. Aquela “tela”, que aos olhos do usuário parece algo banal, logo vira uma dor de cabeça coletiva: não se comunica bem com outras aplicações ou módulos de um mesmo sistema; quebra a ordem conhecida de um processo de negócio; apresenta regras de negócio conflitantes com outras previamente implementadas; recebe frequentes pedidos de alterações etc. Mas o que nos interessa aqui, agora, é que demandas deste tipo carecem de sentido: O que o negócio ganha com isso? Ou o que ele perde se a solicitação não for atendida? E quando chegarem dúzias de demandas parecidas, quais merecerão o início da fila?

    O processo não pode ser mecânico assim. TI não é padaria, com todo respeito às padarias. E usuário, mesmo quando guiado pelas melhores das melhores intenções, não deveria invadir o domínio da solução como no exemplo acima. Ele não deveria pedir uma tela, um módulo ou um sistema. Ele deve explicar suas dores, os seus problemas. Se a solução para eles será uma tela ou um sistema, quem dirá é a organização de TI. E TI toma boas decisões quando as fundamenta através da Análise de Negócios.

    O bom analista de negócios não começa seu trabalho em um projeto anotando os requisitos de um usuário para determinada tela, módulo ou sistema. Ele começa tentando entender e diagnosticar as dores do usuário. O bom analista sabe que nem sempre a solução será um sistema. E é aqui que o trabalho em projetos “custom” se diferencia demais daqueles que na parte anterior chamamos de “pacotes”. Aqui há um problema específico a ser diagnosticado e sanado.

    A necessidade de um diagnóstico rápido e eficaz é o que justifica minha cara de pau de sugerir uma sensível alteração na sequência de perguntas proposta por Dan Roam em “The Back of the Napkin” (Portfolio, 2008). “Por quê” é a primeira pergunta que o analista faz: “Por que este projeto é necessário?”. A resposta e toda a conversa que se desenvolve a partir dela nos ajudam a criar uma das três visões que compõem um modelo de negócios básico, a Visão do Negócio. Esta perspectiva, que pode assumir diversos estilos e formatos, compila todos os objetivos do negócio. Colocando de outra maneira, ela documenta a motivação para o projeto.

    É importante que ela, a Visão do Negócio, não seja confundida com o Documento de Visão. Este apresenta a visão (oh!) da solução. Ao desenvolver a Visão do Negócio, o analista ainda está relativamente distante da solução e sua respectiva visão.

    A visão do negócio pode ser representada por uma única linha em um documento, como por exemplo: “Dobrar o número de visitas realizadas pelos vendedores“. Mas ela também pode ser mais elaborada, como tenta mostrar o diagrama abaixo. A complexidade de um negócio ou a amplitude e criticidade de suas dores determinarão o formato mais adequado para entendimento e documentação¹ dos requisitos do negócio.

    Pois é, apelei para o causo do seu Moreira para dar um pequeno exemplo de diagrama que pode formar a visão do negócio. As duas áreas destacadas mostram todos os requisitos de negócio. O que pode ser apenas uma frase, “Dobrar o número de visitas”, em um diagrama mais elaborado pode ganhar a forma de uma hierarquia de objetivos ou requisitos de negócio. Repare que o “Dobrar nº Visitas” é quebrado em vários objetivos menores. E ele próprio deriva de outro, ou, colocando de uma maneira diferente, é condição para a realização de outro requisito, “Dobrar Faturamento”.

    Muito se fala sobre rastreabilidade de requisitos: “Toli Toli Tolá…” – e a cobla ficou lá², vendendo matrizes de rastreabilidade. Perdão. Para o analista de negócios é fundamental que o aprendizado e desenvolvimento dos requisitos obedeçam uma lógica parecida com a ilustrada no diagrama abaixo:

    A visão do negócio é a representação direta de todos os objetivos e metas, o que chamamos de requisitos do negócio. Todos os demais requisitos, independente do tipo ou nível de granularidade, devem derivar deles. Ou seja, devem mostrar seu *valor* – como apoiarão, direta ou indiretamente, a realização dos objetivos do negócio. Cada caso de uso, por exemplo, deve exibir de forma clara quais são os objetivos atendidos por ele. E estes objetivos devem ter uma ligação nítida com os requisitos de negócio maiores.

    Quando este conceito é bem implementado, a equipe consegue perceber com relativa facilidade o que é e o que não é prioritário em um projeto. No próximo artigo desta série falarei especificamente sobre valor e a priorização de todos os requisitos. Inté!

    .:.

    Observações

    1. Documentação! Palavrinha que causa arrepios, não? Chuto e sugiro que 80% dos artefatos gerados por um analista de negócios vá para o lixo tão logo tenha cumprido sua missão: facilitar o entendimento. Sua manutenção não se justifica na maioria das vezes porque: 1) É cara; 2) É muito frequente. Negócios mudam todo dia. É difícil manter documentos assim 100% sincronizados com a realidade. Acredito que para a maioria das organizações, um diagrama representando cada perspectiva (do Negócio, da Estrutura e dos Processos) seja suficiente. Mas, eu sei: cada caso é um caso.
    2. Não entendeu? Então você não passou sua infância ou juventude no início dos anos 80. Paciência. O “toli toli tolá” era cantarolado pelo Honolável Besoulo Japonês toda vez que ele dava um drible a la Neymar em seu arqui-inimigo, a Cobrinha Azul. Hehe… Ok, sei lá porque me lembrei disso agora. Cobra, Azul, eternamente driblada, Matrizes de Rastreabilidade… há um conjunto aqui… eu sei que tem…
    3. Abstract é outra foto que surrupio da Tanakawho.