Páginas

segunda-feira, 28 de maio de 2007

Cinco tipos de personalidades que você não quer em sua equipe

Há cinco tipos de membros de equipe de projeto que não queremos em nossos projetos - e que você não quer nos seus. Se você notar algumas dessas características abaixo em pessoas com quem você trabalha, você precisa agir para transformá-las em membros de equipe que todos os gerentes de projeto invejam.

O Cowboy: esta pessoa é selvagem e lunática. Cowboys não pensam duas vezes antes de incluir comentários inapropriados ao código, esconder ovos de Páscoa na aplicação, fazer remendos no escopo do projeto. Cowboys frequentemente são trabalhadores inteligentes e rápidos e gostam de ser criativos. Trabalhe com essas pessoas, estabelecendo regras e procedimentos, controle de qualidade, tal como revisões em pares, e conversas diretas sobre o que é permitido.

O Rato: o rato é uma pessoa tímida e retraída que precisa de sua instrução, aprovação e mão forte em cada ação que ela realiza. Ratos podem ser facilmente influenciados pelos membros da equipe, stakeholders, e pelos seus próprios medos de prosseguir no trabalho. Seu trabalho é ensinar os ratos a rugir construindo sua confiança e forçando-os a tomar decisões.

A Rocha: Duro, teimoso e difícil de mudar, esse é a Rocha. Rochas são as pessoas que geralmente tem anos de experiência e querem fazer as coisas à sua maneira porque é a maneira correta. São o tipo de pessoa que dizem, "Há duas maneiras de desenvolver uma aplicação: a minha maneira e a maneira correta - e elas são a mesma". Negocie com a Rocha para estabelecer um comando firme e segui-lo.

O Linguista: Linguistas adoram linguagem, e não sabem quando parar de falar. Suas conversas sem fim consomem tempo de projeto, de reuniões, e roubam tempo de outros desenvolvedores, que estão trabalhando em suas tarefas. Você tem que negociar com essas pessoas diretamente conduzindo-as à direção certa. Se um linguista perturbar a equipe de projeto, você tem que intervir ocasionalmente.

O Tio: Lembra do seu tio favorito? É o cara com todas as brincadeiras, estórias engraçadas e truques de mágica. Você adora o seu tio, mas não quer ele em seu projeto. Tios são normalmente trabalhadores rápidos e supõem que o resto da equipe trabalha tão rápido quanto eles. Dê a eles tarefas mais desafiadoras para garantir que eles não vão ficar entediados e começar a incomodar os ouvidos do restante da equipe.

Traduzido do livro SOFTWARE PROJECT MANAGEMENT FOR DUMMIES de Teresa Luckey e Joseph Phillips lançado em 2006 pela Wiley Publishing.

A morte pela documentação

Frequentemente nós tendemos a pensar na documentação como um componente adicional a um projeto em vez de uma parte real do projeto. A verdade sobre este assunto é que a documentação pode fazer a diferença entre o sucesso e o fracasso de um projeto.

Vez após vez, organizações têm criado bons produtos mas não investido os recursos necessários em sua documentação. Muitos desses produtos se tornaram um fracasso de mercado, não por serem maus produtos, mas porque as pessoas não sabiam como usá-los.

Havia uma grande organização de software que costumava fazer bons pacotes de desenvolvimento. A versão 3 de um software desta companhia era muito bem aceito e tinha grande chance de se tornar a plataforma de desenvolvimento dominante em uma área específica.

Querendo dominar o mercado, a organização investiu todos os seus recursos na versão 4. A interface com o usuário foi mudada na versão 4. Mudaram as opções. Mudaram as chamadas. Mudaram tanto que os usuário teriam dúvidas se a versão 4 era o mesmo produto que a versão 3.

De fato, foi criado um produto de desenvolvimento que estava bem à frente de seu tempo e teria impulsionado dramaticamente a programação. O que aconteceu, na verdade, é que a coisa toda se inverteu e o software foi descontinuado. Enquanto isso, outra organização liberou o software de desenvolvimento que se tornou padrão de fato.

O que deu errado? Como essa organização falhou tão miseravelmente?

Ela vendeu o produto por dois preços. Pelo primeiro preço a empresa entregava apenas a mídia. Pelo segundo preço (quase duas vezes mais) entregava aos usuários a mídia e milhares de páginas de manuais de como usuá-lo.

Muitos programadores pensaram que mudando da versão 3 para a versão 4 estariam fazendo uma mudança evolucionária, e não compraram os manuais. Sem os manuais, os desenvolvedores se perderam sem conseguir imaginar como fazer o que eles precisavam fazer. Frustrados e aborrecidos, os desenvolvedores abandonaram o pacote.

Aqueles que adquiriram os manuais foram literalmente esmagados pelos milhares de páginas espalhadas por cinco livros que se referenciavam mutuamente de tal modo que os usuários tinham que ter todos os livros abertos ao mesmo tempo de maneira a imaginar como fazer o que precisavam fazer. Estes que gastaram o dinheiro extra também abandonaram a nova plataforma.

Naturalmente a plataforma morreu; não porque não era boa, mas porque a documentação a matou. Documentação escrita adequadamente, empacotada adequadamente como um produto de qualidade, deveria impulsionar a empresa para uma posição invejável.

Quando você projetar sua documentação, tenha em mente essa história e assegure que seus produtos não se tornem presa do mesmo fato. Esta catástrofe é bastante fácil de prevenir, mas você deve fazer um esforço consciente de fazer isso.

Traduzido do livro SOFTWARE PROJECT MANAGEMENT FOR DUMMIES de Teresa Luckey e Joseph Phillips lançado em 2006 pela Wiley Publishing.
 
Creative Commons License
This work by Carlos Alberto P. Araújo is licensed under a Creative Commons Atribuição-Uso não-comercial-Compartilhamento pela mesma licença 3.0 Brasil License.