7.12.07

Metodologia "Getting Real", 37signals

"Getting Real" é uma metodologia para gerenciamento de projetos web criada pela surpreendente 37signals, responsável tb por projetos de mega repercussão como o Ruby on Rails e o Basecamp.

O ebook com versão tb em português, é cheio de idéias "provocadoras", interessantes ñ só pra quem desenvolve web, mas para o gerenciamento de projetos em geral.

Vai contra as metodologias + comuns... pra quem é adepto de planejamentos minuciosos, a leitura do Getting Real poderá "chocar" rsrs.. mesmo assim recomendo, verá coisas beem úteis com ctz! ;)

Resumo/Melhores Trechos (clique aqui pra ver)

Faça menos que sua competição

A estratégia de estar um passo a frente, leva a uma briga sem fim. Trabalhar assim é caro, defensivo e paranóico. Empresas assim não pensam para frente, eles pensam apenas no passado. Elas não lideram, elas seguem.

Resolva os problemas simples, deixe os problemas cabeludos, difíceis e desesperadores para os outros. Menos significa: - funcionalidades, - opções/preferências, - pessoas e estrutura empresarial, - reuniões e abstrações.

Qual o seu problema

Faça produtos que resolvam seus próprios problemas. Você será o público-alvo e saberá o que é importante e o que não é.

Se estiver tendo problemas, é provável que centenas de milhares de outras pessoas estão no mesmo barco. Esse é seu mercado.

Quando resolvemos nossos próprios problemas, criamos uma ferramenta que nos apaixona. E paixão é a chave para fazer os outros se sentirem apaixonados sobre ela também.

Financie você mesmo

Investidores querem retorno, e rápido. Vc terá que responder a eles.

Hardware é barato e uma boa parte de grandes softwares de infra-estrutura são código aberto e de graça. Então faça o que puder com o dinheiro e tempo que tem em mãos. E lembre-se, recursos limitados dirigem a inovação.

Fixe o Prazo e o Orçamento, Flexibilize o Escopo

Lançar alguma coisa grande que está um pouco menor em escopo do que o planejado é melhor do que lançar alguma coisa medíocre e cheio de buracos porque precisou atingir uma janela mágica de prazo, orçamento e escopo. Benefícios: priorização e qualidade.

Tenha um Inimigo

Descubra tudo que você não quer que seu projeto seja, eleja o seu Anti-Projeto.

Um bônus que você recebe em ter um inimigo é uma mensagem de marketing muito clara.

Não só eles vão entender seu produto melhor e mais rápido, mas vão tomar um lado. E essa é uma maneira garantida de chamar a atenção e acender uma paixão.

Também é importante não ficar muito obcecado com a concorrência. Analise demais outros produtos e você vai começar a limitar sua maneira de pensar.

Se sua competição é mais rápida, você deve ser mais barato. Se eles vendem a história de saúde, você deve vender a história da conveniência. Não apenas o posicionamento cartesiano x/y do tipo "Somos mais baratos", mas uma história real que é completamente diferente da história que já foi contada.

Não deve ser uma rotina

Se sua aplicação não o excita, algo está errado. Se está trabalhando nela apenas para ganhar dinheiro, isso vai aparecer. Da mesma forma, se você se sentir apaixonado pela aplicação, também vai aparecer no produto final

Permaneça enxuto

Quanto mais massa tiver um objeto, mais energia é necessária para mudar sua direção. É uma verdade tanto para o mundo dos negócios como para o mundo físico.

Massa aumenta com...

* Contratos de longo prazo
* Excesso de pessoas
* Decisões permanentes
* Reuniões sobre outras reuniões
* Processos Burocráticos
* Inventário (físico ou mental)
* Prisão em hardware, software e tecnologia
* Formatos proprietários de dados
* Passado mandando no futuro
* Planejamentos de longo prazo
* Políticas de escritório

Massa se reduz com...

* Pensamentos just-in-time
* Equipes com membros multi-tarefa
* Abraçar limitações, sem aumentá-las
* Menos software, menos código
* Menos funcionalidades
* Equipes pequenas
* Simplicidade
* Interfaces reduzidas
* Produtos de código aberto
* Formatos de dados abertos
* Uma cultura aberta que torna fácil admitir erros

Negócios rápidos, ágeis, e com menos massa podem rapidamente mudar seu modelo de negócios, produtos, funcionalidades e mensagem de marketing. Eles podem cometer erros e corrigí-los rapidamente. Podem mudar suas prioridades, misturar produtos e focar. E, mais importante, podem mudar sua maneira de pensar.

Reduza seus custos de mudança

A mudança é sua melhor amiga. Quanto mais caro for para fazer uma mudança, menos chances ela terá de ser realizada. Se seus competidores podem mudar mais rápido, você se encontra em enorme desvantagem. Mudanças rápidas e baratas são a arma secreta dos pequenos. Mesmo com todo o dinheiro, marketing e pessoas do mundo você não pode comprar a agilidade de ser pequeno.

Use uma equipe de 3 para a 1ª versão: um designer, um desenvolvedor, um integrador pra esses 2.

Pessoas talentosas não precisam de recursos infinitos. Elas prosperam no desafio de trabalhar com restrições e usam a criatividade para resolver problemas.

Se você não pode desenvolver sua primeira versão com apenas três pessoas, então ou você precisa de pessoas diferentes ou diminuir sua versão inicial.

A comunicação flui mais facilmente em equipes pequenas do que em grandes.

Abrace as restrições

Restrições normalmente são vantagens disfarçadas. Ajudam a gastar menos, a focar nas prioridades, a tornar a comunicação mais objetiva.

Seja você mesmo

Diferencie-se das companhias maiores sendo amigável e pessoal. Ser pequeno pode realmente ser uma grande vantagem, especialmente quando isto representa comunicação.

Muitas pequenas empresas cometem o erro de tentarem atuar grande.

Qual é a grande idéia do projeto?

Explicitamente defina a visão principal da sua aplicação. O que a sua aplicação defende? Por que ela existe? Por que ela é diferente?

Antes de começar o design ou a codificação de qualquer coisa você precisa saber o propósito do seu produto – a visão. Pense grande.

A visão irá guiar suas decisões e o manterá em um caminho consistente. Sempre que houver um ponto duvidoso, pergunte, "Estamos nos mantendo coerentes à visão?"

Ignore os Detalhes logo no Começo, Trabalhe do grande para o pequeno

Sucesso e satisfação estão nos detalhes. Entretanto, o sucesso não é a única coisa que encontrará nos detalhes. Também encontrará estagnação, desacordo, reuniões e atrasos.

Da Idéia à Implementação

Vá do brainstorm => aos esboços em papel => aos protótipos em HTML => à codificação

Só é um Problema Quando é um Problema

As pessoas costumam gastar tempo demais logo de cara tentando resolver problemas que elas ainda nem têm. Não esquente com uma coisa até que você tenha de fato que fazê-lo. Não desenvolva demais.

Tome decisões só no momento necessário, pois aí você terá acesso à informação real de que precisa.

Contrate os Clientes Certos

Encontre o nicho de mercado para seu aplicativo e concentre-se somente nele. O cliente nem sempre tem razão. A verdade é que você terá que separar quem é certo e quem é errado para seu aplicativo. Se você tentar agradar todo mundo, não irá agradar ninguém.

Permitiu identificar facilmente quais recursos seriam genuinamente úteis e, mais importante, quais recursos deixar de fora.

Focar um nicho de mercado também torna muito mais fácil divulgar seu software.

Escale somente quando for necessário

Crie uma grande aplicação e depois se preocupe com o que fazer quando ela se tornar animalmente bem-sucedida. Do contrário você o corre o risco de desperdiçar energia, tempo e dinheiro se prendendo a algo que nunca acontecerá.

Acredite ou não, o maior problema não é escalar, é chegar ao ponto de ter de fazê-lo. Sem o primeiro problema, você não terá o segundo.

Faça meio produto e não um produto meia-boca

Cuidado com a visão do software "faz-tudo" no desenvolvimento de uma aplicação. Considere todas as boas idéias que aparecerem ao longo do processo e você acabará apenas com uma versão meia-boca do seu produto. O que você realmente precisa é montar meio produto que detone.

Remova funcionalidades até que você obtenha apenas o essencial. E então, repita o processo.

Os melhores designers e os melhores programadores não são os com as melhores habilidades, ou os dedos mais ágeis, e sim aqueles que podem determinar o que não importa. É aí onde os ganhos reais são feitos.

Faça com que as funcionalidades dêem duro para ser implementadas.

Cada vez que você diz sim para uma funcionalidade, você está adotando um filho. Você tem que levar seu bebê através de toda uma cadeia de eventos (exemplo: design, implementação, testes etc.).

Para cada nova funcionalidade você precisa…

* 1. Dizer não.
* 2. Forçar a funcionalidade a provar seu valor.
* 3. Se "não" novamente, pare aqui. Se "sim", continue…
* 4. Esboce as telas/UI.
* 5. Crie as telas/UI.
* 6. Programe-as.
* 7-15. Teste, aperfeiçoe, teste, aperfeiçoe, teste, aperfeiçoe…
* 16. Cheque para ver se o texto da ajuda precisa ser modificado.
* 17. Atualize o tour do produto (se necessário).
* 18. Atualize a cópia de marketing (se necessário).
* 19. Atualize o Termo de Prestação de Serviço (se necessário).
* 20. Cheque se alguma promessa foi quebrada.
* 21. Cheque se a estrutura de custos foi afetada.
* 22. Publique.
* 23. Cruze os dedos.

Deixe seus clientes serem sua memória. Se a funcionalidade for realmente necessária, eles te lembrarão até que você não consiga esquecer.

Crie softwares voltados para conceitos gerais

Não force convenções. Ao invés disso, faça seu software de modo generalista, assim todos podem encontrar suas próprias soluções. Dê às pessoas só o suficiente para resolver os problemas delas ao modo delas. E então saia do caminho.

Pergunte o que as pessoas não querem

A maior parte das enquetes e pesquisas sobre software são focalizadas em o que as pessoas querem num produto.

E o outro lado da moeda? Porque não perguntar o que as pessoas nao querem? "Se você pudesse remover algo, qual seria?" "O que você não usa?" "O que mais te atrapalha?"

Corra para Rodar o Software

Rodar o software é a melhor maneira de fazer acontecer, reúna sua equipe e jogue fora idéias que não funcionam. Esta deve ser sua prioridade número um.

Evite Preferências

Pode parecer que estamos fazendo um favor aos clientes mas apenas estamos lhes dando mais trabalho. Decida sobre os pequenos detalhes para que seus clientes não precisem.

Feito!

Comece a pensar nisso como uma palavra mágica. Quando algo está feito significa que algum objetivo foi atingido.

Mas espere, e se ferramos e tomamos a decisão errada? Tudo bem. Isso não é cirurgia de cérebro, é uma aplicação web.

Não importa quanto planejamos, com certeza estaremos meio errados de qualquer jeito. Então não faça essa coisa de "pausa para análise". Isso apenas desacelera o progresso e compromete a moral.

Seja um executador

* Idéia Péssima = -1
* Idéia Fraca = 1
* Idéia mais ou menos = 5
* Boa Idéia = 10
* Grande Idéia = 15
* Brilhante Idéia = 20

* Nenhuma execução = $1
* Execução Fraca = $1.000
* Execução mais ou menos = $10.000
* Boa Execução = $100.000
* Grande Execução = $1.000.000
* Brilhante Execução = $10.000.000

Para fazer negócios, você precisa multiplicar os dois.
(Derek Sivers, presidente e programador, CD Baby e HostBaby)

Teste sua aplicação com uso do mundo real

Não há substituto para pessoas reais usando sua aplicação de maneiras reais. Pegue dados reais. Receba feedback real. Então aprimore baseado nessa informação.

* 1. Decida se vale a pena fazer, e se for:
* 2. Faça rápido — Não perfeito. Apenas faça;
* 3. Grave. Faça upload. Publique;
* 4. Veja o que as pessoas acham.
* 5. Decida o que fazer

(Derek Sivers, presidente e programador, CD Baby e HostBaby)

Quebre seu horizonte de tempo e seus problemas

Estimativas que esticam em semanas ou meses são fantasias. A verdade é que simplesmente não sabemos o que vai acontecer. daqui tanto tempo à frente. Quebre seu cronograma em pedaços menores.

Você está enfrentando um problema tão grande que não cabe na sua cabeça? Quebre. Continue dividindo os problemas em pedaços cada vez menores até que você seja capaz de digerí-los.

Tarefas Menores e Cronogramas Menores

Desenvolvedores de software são uma espécie especial de otimistas: quando apresentados a uma tarefa de programação, eles pensam, "Isso será fácil! Não vai levar tanto tempo, afinal de contas".

Então, dê três semanas a um programador para completar a enorme tarefa, e ele gastará duas semanas e meia procrastinando, e então uma programando. O atraso no cronograma provavelmente encontrará os requisitos errados, porque a tarefa se mostrou mais complexa do que parecia. Além disso, quem vai lembrar o que foi acordado entre a equipe três semanas atrás?

Dê a um programador uma tarde para codificar um módulo pequeno, específico e ele vai devorá-lo, pronto para ir para o próximo.

Tarefas menores e cronogramas menores são mais gerenciáveis, escondem menos requisitos mal entendidos e custam menos para você mudar de idéia ou refazer. Cronogramas menores mantém os desenvolvedores engajados e lhes dá mais oportunidades para aproveitar um senso de conquista e menos razões para pensar, "oh, eu tenho tempo suficiente para fazer isso. Por ora, vou terminar de categorizar minhas músicas no meu iTunes".

(Gina Trapani, desenvolvedora web e editora da Lifehacker, o guia da produtividade e software)

Não quebre em áreas

Enquanto a especialização tem suas vantagens, também cria uma situação em que os funcionários só enxergam seus próprios mundos.

Integre sua equipe ao máximo para que exista um diálogo contínuo em todas as etapas do processo.

Melhor ainda, contrate pessoas com múltiplos talentos, que podem atuar em diversas frentes. O resultado final será um produto mais harmonioso.

Tempo sozinho

Pessoas precisam de períodos sem interrupções para terminar o trabalho. Quando você tem um longo período em que não é incomodado, consegue se concentrar. E concentrado se é mais produtivo.

Se concentrar leva tempo. E é exatamente por isso que a interrupção é seu maior inimigo. É como pegar no sono profundo – não se entra no sono profundo do nada, tem que se deitar, dormir e então entrar no sono profundo. Qualquer interrupção o força a começar tudo de novo. O sono profundo é onde a mágica do sono acontece de verdade. A concentração é onde a mágica da produtividade acontece de verdade.

Encontre um jeito de eliminar – ou minimizar – as dependências entre as unidades.

Não tenha reuniões

Reuniões geralmente acontecem quando um conceito não está claro o suficiente. Ao invés de recorrer a uma reunião, tente simplificar o conceito.

Em casos em que reuniões são realmente necessárias (faça disso um raro evento), siga estas regras simples:

* Coloque um alarme pra 30 minutos. Assim que ele tocar, a reunião acabou. Ponto final.
* Chame o menor número de pessoas possível.
* Nunca tenha uma reunião sem uma pauta bem clara.

Procure e Celebre Pequenas Vitórias

A coisa mais importante em desenvolvimento de software é motivação. Ciclos de entregas longos e demorados são assassinos de motivação. Eles separam muito o tempo entre as comemorações.

Contrate menos e mais tarde

Não contrate. Você terá problemas no treinamento, disputas pessoais, problemas de comunicação, pessoas indo em direções opostas e muito mais.

Toda vez que Jack Welch, antigo CEO da GE, precisava demitir alguém, ele não contratava alguém de imediato para substituí-la.

É preferível 1 ótimo profissional do que 5 medianos. 5 Antonio Salieri's não vão produzir um Requiem, de Mozart.

Contrate depois do "test-drive"

Antes de contratar alguém, passe a ele um pequeno projeto antes. Vamos ver como ele assume o projeto, como ele se comunica, como ele trabalha, etc. Você verá rapidamente se a pessoa é ou não o que você precisa.

Não esqueça de avaliar também:

* Qualidade do trabalho
* Nível de Paixão
* Perspectiva Cultural
* Porcentagem de Finalização
* Lado social

Procure por generalistas que aprendem rápido em vez dos especialistas limitados.

Vá com feliz e mediano em vez de frustrado e grande.

Encontre alguem entusiasmado. Alguém em quem possa confiar para fazer as coisas quando deixado sozinho. Alguém que sofreu em uma empresa grande, devagar e deseja um novo ambiente. Alguém que está excitado para construir o que você está construindo. Alguém que odeia as mesmas coisas que você. Alguém que mal consegue esperar para subir a bordo do seu trem.

Contrate bons escritores. Se está tentando decidir entre poucas pessoas para preencher uma posição, sempre contrate o melhor escritor. Isso porque ser um bom escritor é mais do que apenas palavras. Bons escritores sabem como se comunicar. Eles tornam as coisas mais fáceis de entender. Eles podem se colocar no lugar dos outros. Eles sabem o que omitir. Eles pensam claramente. E essas são as qualidades que você precisa.

Não Há Nada de Funcional em uma Especificação Funcional

São fantasias, são apenas uma forma de acalmar os ânimos, apenas levam à ilusão de um acordo, forçam a tomada das decisões mais importantes justamente quando se tem o mínimo de informações sobre o todo, geram excesso de funcionalidades, não deixarão que você evolua

Reduza o impacto das más notícias com avisos prévios e tratamento privilegiado

Faça Lançamentos como em Hollywood

1) Trailer, 2) Prévia e 3) Lançamento.

um bom site promocional também. O que devemos incluir nesse site? Algumas idéias:

* Apresentação: Explique sobre a aplicação e seus benefícios.
* Turismo: Guie as pessoas pelas várias funcionalidades
* Fotos de tela e vídeos: Mostre às pessoas como sua aplicação realmente se parece e como usá-la.
* Manifesto: Explique a filosofia e idéias por trás dela.
* Estudos de Caso: Dê exemplos reais que mostram o que é possível.
* Euforia: Frases testimoniais de clientes, revisões, imprensa, etc.
* Fórum: Ofereça um local para membros da comunidades se ajudarem uns aos outros.
* Precificação e Assinatura": Leve as pessoas à aplicação o mais rápido possível.
* Weblog": Blogs mantém seu site atualizado com notícias, dicas, etc.

Derrube as paredes entre o desenvolvimento e o suporte.

Tempo rápido de atendimento em consultas de suporte devem ser prioridade máxima

Mesmo que não tenha uma resposta perfeita, diga alguma coisa.

Use fórums ou chats para deixar os clientes se ajudarem

Ainda sobre Lançamentos

Lance uma grande atualização 30 dias após o lançamento

Uma atualização rápida mostra embalo. Mostra que estamos ouvindo. Mostra que temos mais cartas na manga.

Mostre que seu produto está vivo mantendo um blog operacional do desenvolvimento do produto após o lançamento

Coisas a incluir

* Faq (Perguntas e Respostas Freqüentes)
* How-tos (Instruções passo-a-passo)
* Dicas & Truques
* Novas Funcionalidades, atualizações e correções
* Burburinho/Imprensa

Um blog não mostra apenas que seu aplicativo está vivo, mas faz sua empresa parecer mais humana. Novamente, não tenha medo de manter o tom da conversa amigável e pessoal.



Gostou? Compartilhe:
TwitterStumbleupondel.icio.us

1 comentários:

Bruno disse...

Gostei muito pelo pouco que li sobre o livro. Trabalho numa Estatal e sempre esbarro com excesso de burocracia, reuniões desnecessárias que não resolvem nada. To começando a achar q estou no lugar errado. rsrs

Blog Widget by LinkWithin