Advertências, disclaimers e outros avisos prévios
Apenas para esclarecer, aqui estão nossas respostas para algumas reclamações que ouvimos de vez em quando:
"Essas técnicas não funcionarão para mim."
Cair na Real é um sistema que funcionou incrivelmente para nós. Dito isso, as ideias neste livro não se aplicam a todos os projetos sob o sol. Se você está construindo um sistema de armas, uma usina de controle nuclear, um sistema bancário para milhões de clientes ou algum outro sistema crítico para a vida/finanças, você vai se assustar com nossa atitude laissez-faire. Vá em frente e tome precauções adicionais.
E não tem que ser uma proposta de tudo ou nada. Mesmo que você não possa abraçar completamente Caindo na Real, com certeza há pelo menos algumas ideias aqui que você pode introduzir sorrateiramente.
"Vocês não inventaram essa ideia."
Não estamos reivindicando ter inventado essas técnicas. Muitos desses conceitos existem de uma forma ou de outra há muito tempo. Não fique irritado se você ler alguns dos nossos conselhos e isso lembrar algo que você já leu no blog de fulano ou em algum livro publicado há 20 anos. É definitivamente possível. Essas técnicas não são exclusivas do Basecamp. Estamos apenas dizendo como trabalhamos e o que foi bem-sucedido para nós.
"Vocês veem as coisas de forma muito preto no branco."
Se nosso tom parece o de donos da verdade, tenha paciência conosco. Achamos melhor apresentar as ideias de forma ousada do que ser indeciso sobre isso. Se isso parecer arrogante ou presunçoso, que assim seja. Preferimos provocar do que diluir tudo com "depende..." Claro que haverá momentos em que essas regras precisarão ser estendidas ou quebradas. E algumas dessas táticas podem não se aplicar à sua situação. Use seu julgamento e imaginação.
"Isso não funcionará dentro da minha empresa."
Acha que é grande demais para Cair na Real? Até a Microsoft está Caindo na Real (e duvidamos que você seja maior que eles).
Mesmo que sua empresa normalmente opere em cronogramas longos com grandes equipes, ainda há maneiras de Cair na Real. O primeiro passo é se dividir em unidades menores. Quando há muitas pessoas envolvidas, nada é feito. Quanto mais enxuto você for, mais rápido — e melhor — as coisas são feitas.
Tudo bem, pode ser necessário algum esforço de vendas. Convença sua empresa sobre o processo de Cair na Real. Mostre a eles este livro. Mostre os resultados reais que você pode alcançar em menos tempo e com uma equipe menor.
Explique que Cair na Real é uma maneira de baixo risco, baixo investimento para testar novos conceitos. Veja se você pode se separar da nave-mãe em um projeto menor como prova de conceito. Demonstre resultados.
Ou, se você realmente quer ser ousado, vá na surdina. Fique fora do radar e demonstre resultados reais. Essa é a abordagem que a equipe do Start.com usou enquanto Caía na Real na Microsoft. "Eu assisti a equipe do Start.com trabalhar. Eles não pedem permissão", diz Robert Scoble, Evangelista Técnico na Microsoft. "Eles têm um chefe que fornece cobertura. E eles mordem um pouco de cada vez e respondem ao feedback."
Lançando o Start.com da Microsoft
Em grandes empresas, processos e reuniões são a norma. Muitos meses são gastos planejando funcionalidades e discutindo detalhes com o objetivo de todos chegarem a um acordo sobre o que é a coisa "certa" para o cliente.
Esse pode ser o caminho certo para software embalado, mas com a web temos uma vantagem incrível. Simplesmente lance! Deixe o usuário dizer se é a coisa certa e se não for, ei, você pode consertá-lo e lançá-lo na web no mesmo dia, se quiser! Não há palavra mais forte que a do cliente — resista à vontade de se engajar em reuniões longas e argumentos. Apenas lance e prove um ponto.
Muito mais fácil dizer do que fazer — isso implica:
Meses de planejamento não são necessários.
Meses escrevendo especificações não são necessários — as especificações devem ter as bases pregadas e os detalhes descobertos e refinados durante a fase de desenvolvimento. Não tente fechar todas as questões abertas e pregar cada detalhe antes do desenvolvimento começar.
Lance menos funcionalidades, mas funcionalidades de qualidade.
Você não precisa de uma abordagem de grande impacto com um lançamento totalmente novo e um monte de funcionalidades. Dê aos usuários peças pequenas que eles possam digerir.
Se houver bugs menores, lance assim que tiver os cenários principais resolvidos e envie as correções de bugs para a web gradualmente depois disso. Quanto mais rápido você receber o feedback do usuário, melhor. Ideias podem soar ótimas no papel, mas na prática se revelam subótimas. Quanto antes você descobrir sobre problemas fundamentais que estão errados com uma ideia, melhor.
Uma vez que você iterar rapidamente e reagir ao feedback do cliente, você estabelecerá uma conexão com o cliente. Lembre-se, o objetivo é conquistar o cliente construindo o que eles querem.
—Sanaz Ahari, Gerente de Programa do Start.com, Microsoft