Resumo De Livro: Caindo na real (David Heinemeier Hansson, Jason Fried e Matt Linderman)

2025-06-09

Este é um resumo adaptado para revisão futura. O método de escrita é ortodoxo.

Nota: 10/10

Dificuldade: Fácil

Título original: Getting Real - Jason Fried, (Estados Unidos 1974 - 51y ou 52y em 2026-06-17), David Heinemeier Hansson a.k.a. DHH (Copenhague/Dinamarca 15-10-1979 - 46y em 2026-06-17), Matt Linderman

writebook-getting-real-en

resenha-getting-real-pt-br-luiztools-webarchive

resenha-getting-real-pt-br-luiztools-archive.is

SUMÁRIO

c01-intro

c02-a-linha-de-largada

c03-permaneça enxuto

c04-prioridades

c05-selecao-de-funcionalidades

c06-processo

c07-a-organizacao

c08-contratando

c09-design-de-interface

c10-codigo

c011-palavras

c12-precificacao-e-assinatura

c13-promocao

c14-suporte

c15-pos-lancamento

c16-conclusao

01 intro

Essential, menos e menos, início pela interface e experiência

Resolver problemas e não a ideia (achismo)

Uma página web pronta é realidade

Software vigoroso, cada parte tem sentido - Os Elementos de Estilo de William Strunk Jr.

Caindo na Real se livra de…

Você não precisa de toneladas de dinheiro ou uma equipe enorme ou um ciclo de desenvolvimento longo para construir grandes softwares. Essas coisas são ingredientes para aplicações lentas, esfumaçadas, que não mudam. Caindo na Real usa o caminho oposto.

Você precisa construir, lançar e refinar. Então recomece e repita.

02 a linha de largada

Faça menos que sua competição

Resolva os problemas simples, deixe os problemas cabeludos, difíceis e desesperadores para os outros. Pegar o filé.

Construa software para si, resolver seus próprios problemas, scratching your own itch

37signals empresa de design, ~~Basecamp~~ nasceu para facilitar gestão de projetos com clientes

Chutes, desenvolvimento de código aberto, 90% scratching your own itch

Acho que é uma das razões que as pessoas chegam em casa após um dia duro de trabalho de codificação e ainda trabalham com código aberto: é relaxante. Dave Thomas, The Pragmatic Programmers

Se vai viver com alguma coisa anos, três anos, o resto de sua vida, precisa se importar sobre isso.

Malcolm Gladwell, autor (de Algumas Finas Fatias de Malcolm Gladwell)

Financie Você Mesmo

Bootstrap

Restrição gera criatividade, construção rápida e de qualidade

Signal vs Noise - Entrepreneurs, angels, and the cost of launch

Signal vs Noise - Entrepreneurs, angels, and the cost of launch - archive.is

Signal vs Noise - Entrepreneurs, angels, and the cost of launch - webarchive

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

Lance dentro do prazo e do orçamento

Mantenha tempo e dinheiro, redução escopo

Se não puder encaixar tudo dentro do prazo e orçamento planejados então não aumente o tempo e o custo. Em vez disso, puxe o escopo para trás. Sempre existe tempo para adicionar coisas mais tarde - o mais tarde é eterno, o agora está voando.

Essa decisão implica em:

Priorização - o que importa

Realidade - expectativa, tempo, orçamento e escopo, medíocre

Flexibilidade - melhor meio produto a produto medíocre

Tenha um inimigo

Pegue uma briga

O que não construir, Basecamp, antagônico, MS Project

Entendemos que gerenciamento de projetos não é sobre tabelas, gráficos, relatórios e estatísticas - é sobre comunicação.

Também não é sobre um gerente de projetos sentando lá no alto e distribuindo um plano de projetos. É sobre todos assumindo responsabilidades juntos para fazer o projeto funcionar.

Não siga o líder

Marketeiros (e todos os seres humanos) são bem treinados para seguir o líder. O instinto natural é descobrir o que funciona para a concorrência e então tentar superá-los - em ser mais barato que seu competidor que compete no preço, ou mais rápido que seu competidor que compete na velocidade. O problema é que uma vez que o consumidor já comprou a história de alguém e acredita nessa mentira, persuadi-lo a mudar é a mesma coisa que persuadi-lo a admitir que estava errado. E as pessoas odeiam admitir que estão erradas.

Competição na história diferente

Qual é o problema chave?

Não Deveria ser uma Rotina

Sua paixão - ou falta de - vão aparecer

Quanto menos sua aplicação se tornar uma rotina para construir, melhor será.

A presença de paixão

Paixão e indiferença no design do produto

03 permaneça enxuto

Menos Massa

Quanto mais enxuto for, mais fácil é para mudar

Grande massa difícil mudança, física e na web, mudança fácil e barata

Massa aumenta com…

Massa se reduz com…

Diminua seu Custo de Mudança

Permaneça flexível reduzindo os obstáculos à mudança

Pequeno, rápido, grande preço de mudar, inércia

Emergência

Emergência como impulso a mudança enxuta

Os Três Mosqueteiros

Use uma equipe de três para a versão 1.0

3 pessoas

Versão 1.0 deve sair, pessoas erradas, diminuir escopo

Pessoas talentosas não precisam de recursos infinitos. Elas prosperam no desafio de trabalhar com restrições e usam a criatividade para resolver problemas. Falta de recursos humanos força-o a lidar com sacrifícios mais cedo, o que é ótimo. Fará você entender suas prioridades mais cedo do que mais tarde.

Lei de Metcalfe e equipes de projeto

Lei de Metcalfe, valor da rede aumenta ao quadrado, inversamente proporcional a eficiência da equipe nessa rede

O que o “valor” representa na Lei de Metcalfe:

Interpretações do “valor”:

O “valor” na Lei de Metcalfe pode ser interpretado de várias maneiras, dependendo do tipo de rede:

  1. Valor de Conexão e Comunicação:
  1. Valor de Rede (Network Effects):
  1. Valor de Informação e Conteúdo:

Por que o valor aumenta ao quadrado (n²):

O aumento do valor ao quadrado (exponencial) acontece porque cada novo usuário na rede aumenta o número de possíveis conexões ou interações em uma taxa muito maior do que o próprio número de usuários.

Em resumo:

O “valor” na Lei de Metcalfe representa a utilidade, a capacidade de conexão, a influência ou o impacto de uma rede. Ele cresce exponencialmente porque cada novo usuário aumenta as oportunidades de interação e valor dentro da rede, não linearmente. A lei explica por que redes com muitos usuários tendem a ser muito mais valiosas do que redes com poucos usuários.

O fluxo da comunicação

Less is More: Jumpstarting Productivity with Small Teams - Steve McConnell - waybackmachine

Less is More: Jumpstarting Productivity with Small Teams - Steve McConnell - archive.is

Abrace as restrições

Deixe as limitações lhe guiar para soluções criativas

Restrições como guia, trabalhar com o que tem, melhora na comunicação

Pequenas iterações

Combata a destruição

Funcionalidade inútil, consumo de prazo

Seja Você Mesmo

Diferencie-se das companhias maiores sendo amigável e pessoal

Ser pequeno como vantagem, pessoalidade, melhor comunicação

Seja orgulhoso, desafiadoramente sincero

A real sobre o tamanho da companhia

Sempre disponível

Fácil contato com a equipe

04 prioridades

Qual é a Grande Ideia?

Diferencie-se das grandes empresas sendo pessoal e amigável

Missão da sua aplicação, visão e propósito, antes de design e código

Exemplo 37 signals

Com o Basecamp, por exemplo, a visão era “Gerenciamento de Projetos é comunicação”. Sentimos fortemente que comunicação efetiva em um projeto leva à propriedade coletiva, ao envolvimento, ao investimento e ao momento. Traz todos à mesma página trabalhando em direção a um objetivo comum. Sabíamos que se Basecamp pudesse atingir isso, todo o resto entraria na linha.

A visão é o motivo porque pulamos painéis, gráficos, tabelas, relatórios, estatísticas e planilhas e ao invés disso focamos na prioridade da comunicação como mensagens, comentários, listas de tarefas e compartilhamento de arquivos. Tome a grande decisão sobre a visão logo no começo e todas as pequenas decisões futuras se tornam muito mais simples.

Filosofia do Quadro Branco

Requisitos importantes como guia

Faça um Mantra

Organizações precisam de pontos-guia.

Precisam de linhas gerais; funcionários precisam saber a cada dia quando acordam porque estão indo trabalhar. Essas linhas devem ser curtas e doces, e bem compreensivas: Por que você existe? O que o motiva? Chamo isso de mantra - uma descrição de três ou quatro palavras de porque você existe. - Guy Kawasaki, autor (de Make Mantra)

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. Essas coisas podem acabar com a moral e diminuir suas chances de sucesso.

O Diabo está nos Detalhes

Detalhes imediatos, desenho ruim

Você deve começar pegando as proporções corretas da cena toda. Então rascunha os grandes objetos na sua cena, indo até os menores. O rascunho deve ser bem vago nesse ponto. Então pode proceder sombreando, o que consiste em dar volume à vida. Você começa com apenas três tons (claro, médio, escuro). Isso dá um rascunho de tons. Então, para cada porção do seu desenho reavalia três tons e os aplica.

Faça isso até os volumes aparecerem (requer múltiplas iterações)…

Funciona do grande para o pequeno. Sempre.

Ignore details early on webarchive

Ignore details early on archive.is

Só é um Problema Quando é um Problema

Não desperdice tempo com problemas que você ainda não tem

Operação enxuta

Apenas se vire

Preocupação com problema não existente, resolver quando for necessário

…lançamos o Basecamp sem a habilidade de cobrar os clientes! Como o produto é cobrado mensalmente, sabíamos que teríamos um intervalo de 30 dias para dar um jeito. Usamos aquele tempo para resolver problemas mais urgentes e então, após o lançamento, enfrentamos a cobrança. Deu certo (e nos forçou a adotar uma solução simples, sem firulas desnecessárias)…

Paliativo, jogar limpo com cliente

Resumo da Ópera: Tome decisões só no momento necessário, pois aí você terá acesso à informação real de que precisa. Entrementes você estará em condições de prestar atenção às coisas que requerem cuidado imediato.

Nota pessoal: adendo, vale planejamento antes de tomar qualquer decisão precipitada. Decisões estratégicas, ainda que devam ser tomadas no momento necessário, não pode ser um fator de pressão

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. A boa notícia é que a Internet torna mais fácil do que nunca encontrar as pessoas certas.

Se você tentar agradar todo mundo, não irá agradar ninguém.

A Melhor Decisão Que Já Tomamos

Nichado, para resolver dor específica, ICP, PLG

Métricas e Marketfit de Micro-SaaS webarchive

Métricas e Marketfit de Micro-SaaS archive.is

Escale mais Tarde

Você ainda não tem um problema de escalabilidade

Só se preocupe com escalabilidade quando chegar lá

Faça Software que tem Opinião

Seu aplicativo deve tomar partido

Software com visão e direto, software flexível aberto a novas funções é ruim, wikipedia

Nossos aplicativos trilharam um caminho parecido. Eles não tentam ser todas as coisas para todas as pessoas. Eles têm uma atitude. Eles vão atrás de clientes que são no fundo parceiros. Eles têm apelo para as pessoas que partilham de nossa visão. Ou se está do lado de dentro ou se está do lado de fora.

05 Seleção de Funcionalidades

Meio, Não Meia-Boca

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

Cuidado no desenvolvimento web, considerações boas ideias, fim produto meia boca, ideia meio produto que funcione

Essencial apenas

Isso Simplesmente Não Importa

Apenas o essencial

Por que não fez, porque não importa

Exemplo Campfire, negrito, horário, pessoas

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

A maior parte do tempo que você gasta é perdido em coisas que não importam. Se você puder cortar o tempo pensando no que não importa, você atingirá níveis de produtividade que você jamais imaginou.

Comece com Não

Faça com que as funcionalidades deem duro para ser implementadas

Um sim para funcionalidade, como filho (exemplo: design, implementação, testes etc.)

Remoção, clientes irados

Não concorde com tudo

Não para uma funcionalidade, recorrência, consideração dela

E o que dizer às pessoas que reclamam quando nós não adotamos a sua ideia?

Lembre-os do porque eles gostam da aplicação em primeiro lugar.

Nós não queremos milhares de funcionalidades

Say NO by default - Derek Sivers

How not to buy happiness Robert Frank

Custos Ocultos

Exponha o preço das novas funcionalidades

Custo da nova funcionalidade, Loop de funcionalidades,

Nós recebemos pedidos para adicionar uma aba de reuniões ao Basecamp. Parece simples até que você examine com mais cautela. Pense em todos os diferentes itens que uma aba de reuniões precisaria: localização, hora, sala, pessoas, convites por email, integração com o calendário, documentação de suporte, etc. Isso sem mencionar que nós teríamos que modificar as imagens de promoção, as páginas do tour, páginas do faq/ajuda, contrato de prestação de serviço e mais. Antes que você note, uma idéia simples pode ser tornar uma dor de cabeça enorme.

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 - Teste.

8 - Aperfeiçoe.

9 - Teste.

10 - Aperfeiçoe.

11 - Teste.

12 - Aperfeiçoe.

13 - Teste.

14 - Aperfeiçoe.

15 - Teste.

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.

Você Pode Lidar com Isso?

Crie algo que você possa gerenciar

Crie produtos e ofereça serviços que você possa gerenciar. É fácil fazer promessas. É bem mais difícil mantê-las.

Tenha certeza de que, seja lá o que você fizer, seja algo que você possa realmente sustentar - organizacional, estratégica e financeiramente.

Soluções Humanas

Crie softwares voltados para conceitos gerais e incentive as pessoas a criar suas próprias soluções

Dê as pessoas o suficiente, exemplo do Ta-da list

Esqueça Pedidos de Funcionalidades

Deixe os clientes informarem o que é importante

Funcionalidade com solicitação recorrente, lembrança pelos clientes, ler e jogar fora, sem preocupação, lembrança constante

Segure as Rédeas

Pergunte o que as pessoas não querem

Inovação aparece quando dizemos não à 1000 coisas para termos certeza que não estamos seguindo o caminho errado ou tentando fazer coisas demais. Nós estamos sempre pensando em novos mercados para entrar, mas somente dizendo não para isso que você pode se concentrar no que realmente importa.

Steve Jobs, CEO, Apple (de A Semente de Inovação da Apple) Archive

Steve Jobs, CEO, Apple (de A Semente de Inovação da Apple) Archive.is

06 processo

Corra para Rodar o Software

Pegue algo real e ponha-o para rodar rapidamente

Execução, feedback real

As coisas reais levam ao acordo

Execução leva a convergência

Christopher Alexander, Professor de Arquitetura (de Contrastando Conceitos de Harmonia na Arquitetura) webarchive

Christopher Alexander, Professor de Arquitetura (de Contrastando Conceitos de Harmonia na Arquitetura) archive.is

Faça Funcionar o Mais Rápido Possível

Filosofia keppeana da ação aplicada a construção

Enxague e Repita

Trabalhe por iterações

Começar logo e certo (TDD), uso e iteração

Iterações levam à liberação

PDCA na iteração

Talvez você seja mais esperto do que eu

Demanda puxada via cliente, iteração e revisão

Da Idéia à Implementação

Vá do brainstorm à esboços à HTML à codificação

Rito 37signals

Brainstorm

Esse estágio nao é sobre os mínimos detalhes. É sobre grandes questões. O que a aplicação precisa fazer? Como saberemos quando será útil? O que exatamente faremos? Isso é sobre idéias de alto nível, nao discussões no nível dos pixels.

História do Basecamp, própria dor

Para o Basecamp, nós olhamos para nossas próprias necessidades. Queríamos publicar atualizações de projeto. Queríamos participação dos clientes. Sabíamos que projetos tinham datas-chave. Queríamos centralizar arquivos para que as pessoas pudessem revisar coisas antigas com facilidade. Queríamos ter uma visão da figura maior, uma vista aérea do que estava acontecendo com todos os nossos projetos. Juntas, estas premissas e algumas outras, serviram como nossa fundação.

Papel de Padeiro

Importância no IHC e UX

Crie telas HTML

Rascunho em tela real

Codifique

Quando o protótipo parecer bom e demonstrar o suficiente das funcionalidades necessárias, vá em frente e conecte o código de programação. Durante todo esse processo, se lembre de permanecer flexível e esperar múltiplas iterações. Você deve se sentir livre para jogar fora qualquer parte entregável de qualquer passo particular e começar novamente se ela se mostrar lixo. É natural passar por esse ciclo múltiplas vezes.

Evite Preferências

Decida sobre os pequenos detalhes para que seus clientes não precisem

Forma simples como decisão

Preferências são uma maneira de evitar tomar decisões difíceis

Simplicidade como apontamento da ação, menos sempre

Menos, código, teste, design, bug, leiaute quebrado

Tome a decisão

Tome as decisões simples no lugar dos clientes.

Sim, podemos tomar uma decisão ruim. Mas e daí? Se fizermos isso, as pessoas vão reclamar e nos dizer sobre isso. Como sempre, podemos ajustar. Cair na Real é justamnete sobre ser capaz de mudar em tempo real.

Preferências Têm um Custo

Muito custo e pouco valor

Havoc Pennington, líder técnico, Red Hat (de Software Livre e boas interfaces de usuário) Webarchive

Havoc Pennington, líder técnico, Red Hat (de Software Livre e boas interfaces de usuário) Archive.is

Decisões são temporárias então faça a escolha e siga em frente

Feito, objetivo atingido, menos avaliação com pausa, mais andamento e importância na tomada de decisão

Aceite que decisões são temporárias. Aceite que erros vão acontecer e entenda que não tem nada demais enquanto estivermos fazendo correções rapidamente. Execute, construa momento, e siga em frente.

Seja um Executador

Execução tem valor, ideia não

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. A idéia mais brilhante, sem nenhuma execução, vale $20. A idéia mais brilhante necessita de grande execução para valer $20.000.000. Esse é o motivo porque não quero ouvir idéias de outras pessoas. Não estou interessado até ver suas execuções.

Derek Sivers

Teste ao Ar Livre

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.

Teste de UX assistido não tem bons resultados, receio da observação

Em vez disso, lance versões beta para alguns poucos selecionados dentro da própria aplicação real. Faça com que usem as funcionalidades do beta ao lado das funcionalidades lançadas. Isso irá expôr essas funcionalidades a dados reais das pessoas e a fluxos verdadeiros.

O Livro Beta

Dave Thomas, The Pragmatic Programmers sobre lançar o livro agile web development with rails, pensamento de editor, mentalidade raiz tecnologia anterior, lançamento antecipado, feedback, entrega melhor

Faça isso rápido

  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.

Encolha Seu Tempo

Quebre

Quebrar tarefas e problemas em pequenos pedaços, entregar e resolver

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.

Fatores Verdadeiros

Dizer não sei, para melhor entendimento, da próxima vez que alguém o pressionar por uma resposta exata a uma questão desconhecida - seja sobre uma data de entrega, o custo final do projeto ou o volume de leite que caberia no Grand Canyon

Resolva Aquele Problema Que Está Te Encarando na Cara

Algumas vezes resolver os próximos vinte problemas não é tão útil ou prudente quanto resolver aquele um que está nos encarando diretamente na nossa cara. Não foi apenas uma pequena vitória contra o SPAM (todas as vitórias contra SPAM são pequenas), mas uma vitória para aqueles de nós que apreciam os resultados simples e diretos sobre ser um desenvolvedor web.

07 a organização

Unidade

Áreas, mundo próprio, integração e colaboração multidisciplinar

Não quebre em áreas

Tempo Sozinho

Pessoas precisam de períodos sem interrupções para terminar o trabalho

Sobre trabalhar sozinho: O tempo sozinho é onde progressos de verdade acontecem

Se Concentrando

Eliminação dos pontos de distração

Joel Spolsky, desenvolvedor de software, Fog Creek Software (de De Onde Essas Pessoas Tiram Essas Idéias (Não Originais?) Webarchive

Joel Spolsky, desenvolvedor de software, Fog Creek Software (de De Onde Essas Pessoas Tiram Essas Idéias (Não Originais?) Archive.is

Reuniões São Tóxicas

Você precisa mesmo de 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, para que você possa discutí-lo rapidamente por e-mail ou IM ou Campfire. O objetivo é evitar reuniões.

Cada minuto que você gasta em uma reunião é um minuto que você poderia estar trabalhando. Não existe nada mais tóxico à produtividade do que uma reunião. Aqui vão alguns motivos:

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

Existem muitas reuniões. Fazer reuniões que não fazem sentido é uma tarefa improdutiva. Só agende uma reunião quando você tem um assunto muito importante para discutir e você quer ou precisa de uma idéia, aprovação ou aval.

Mesmo assim, resista bravamente à tentação de convidar todo mundo - não desperdice o tempo das outras pessoas sem necessidade.

Lisa Haneberg, autora (de Não Deixe as Reuniões Ditarem as Regras!)

Quebre-as

Quebrar equipes, complexidade de comunicação problemas técnicos

Grupo Ganssle (de Mantenha Pequeno) Webarchive

Grupo Ganssle (de Mantenha Pequeno) archive.is

Procure e Celebre Pequenas Vitórias

Entregue algo hoje

Ciclo longo de entrega, drenagem de motivação

08 contratando

Contrate Menos e Contrate Mais Tarde

Adicione devagar para andar rápido

Você não precisa de tanta gente

Lei de Brooks

Adicionar pessoas a um projeto de software atrasado vai atrasá-lo ainda mais.

Um único excelente profissional, melhor a muitos em mesma tarefa, gargalos de comunicação e ordenação

Cinco Antonio Salieri’s não vão produzir um Requiem, de Mozart. Nem se trabalhassem por 100 anos.

Joel Spolsky, desenvolvedor de software, Fog Creek Software (de Acertando as Notas Maiores) Webarchive

Joel Spolsky, desenvolvedor de software, Fog Creek Software (de Acertando as Notas Maiores) Archive.is

Chute os Pneus

Trabalhe com possíveis funcionários na base do “teste antes”

Pequenos projetos antes de uma efetivação, comunicação, resiliência, design de telas, percepção, tempo pequeno projeto 20-40h

Comece com pouco

Ações, não palavras

Julgue potenciais contratações de tecnologia em contribuições open source

Contratação técnica, contribuição em código livre/aberto

Como diz aquele velho ditado: se quer algo feito, peça à pessoa mais ocupada que você conhece. Jamis e David são dois dos maiores contribuidores do Rails e ainda conseguem dirigir tecnicamente a 37signals. Pessoas que amam programar e terminar seus projetos são exatamente o tipo de pessoa que você quer em sua equipe.

David Heinemeier Hansson, desenvolvedor de software, criador do Ruby on Rails, co-fundador da 37signals, (de Reduza o risco, contrate de open source), Webarchive

David Heinemeier Hansson, desenvolvedor de software, criador do Ruby on Rails, co-fundador da 37signals, (de Reduza o risco, contrate de open source), Archive.is

Procure Indivíduos Equilibrados

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

Nunca contrataremos alguém que seja um arquiteto de informação. É simplesmente específico demais.

Com uma equipe pequena como a nossa, não faz sentido contratar pessoas com um conjunto de conhecimento tão limitado. Equipes pequenas precisam de pessoas que possam vestir diferentes chapéis. Precisamos de designers que saibam escrever. Precisamos de programadores que entendam de design.

Todos devem ter noção de como arquitetar informação (seja lá o que isso signifique). Todos precisam ter mentes organizadas. Todos precisam saber se comunicar com clientes. E todos precisar querer e serem capazes de diminuir a marcha pela estrada. Tenha em mente que equipes pequenas eventualmente precisam mudar de direção rapidamente. Queremos alguém que possa se ajustar, aprender e fluir ao contrário de um pé-na-lama que só consegue fazer uma coisa.

Você Não Pode Falsificar Entusiasmo

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

Mediano entusiasmado a expert frustrado,

Encontre alguem entusiasmado.

Pontos extras por fazer perguntas

Candidatos com perguntas inteligentes, interesse e sugestões no problema

Artesãos de Palavras

Contrate bons escritores

Na decisão para contratação, escolher o melhor escritor, saber comunicar

Uma Mente Organizada

Boa escrita, capacidade de síntese e organização

Escrita Clara leva a Pensamento Claro

Você não sabe o que sabe até tentar expressar esse conhecimento. Boa escrita é em parte uma questão de caráter. Em vez de fazer o que é fácil para você, faça o que é mais fácil para seu leitor.

Michael A. Covington, professor de ciências da computação Universidade da Geórgia (de Como Escrever mais Claramente, Pensar mais Claramente e aprender Material Complexo mais Facilmente)

09 design de interface

Primeiro a Interface

Desenhe a interface antes de começar a programar

Gerar e mudar código, gargalo, desenho não

Venda, interface, pessoas tocam e vêem, código primeiro, morosidade para pegar furos

A Caneta Laranja que Iniciou Blinksale

Construção do saas Blinksale, rabisco, HTML, estimativa, execução e revisão, Josh Williams criador

Design de Epicentro

Comece do núcleo da página e construa para fora

Conteúdo centrado primeiro para construção, depois bordas

Solução de Três Estados

Faça design para os estados regular, branco e erro

Para cada tela, você precisa considerar três estados possíveis:

Regular

A tela que as pessoas vêem quando tudo está funcionando bem e sua aplicação é preenchida com dados.

Branco/Vazio

A tela que as pessoas vêem quando estão usando a aplicação pela primeira vez, antes de dados serem inseridos.

Erro

A tela que as pessoas vêem quando alguma coisa dá errado. O estado regular é trivial. É a tela onde você vai gastar a maior parte do tempo.

A Tela em Branco

Supere as expectativas com uma primeira experiência convincente

Tela em branco, porta de entrada, sensação o que está perdendo

O que você deve incluir em uma tela em branco que ajuda?

Use como uma oportunidade de inserir pequenos tutoriais e caixas de ajuda. Dê uma foto da tela final como exemplo da página populada com dados para que as pessoas saibam o que esperar (e porque devem ficar por lá).

Explique como começar, como a tela vai ficar exatamente, etc.

Responda as perguntas chave que visitantes de primeira viagem fazem:

O que é esta página? O que faço agora? Como essa tela vai ficar quando estiver cheia?

Supere as expectativas e ajude a reduzir frustrações, intimidações e a confusão em geral. Primeiras impressões são cruciais.

Se você falhar em fazer o design de uma tela em branco bem pensada, criará impressão negativa (e falsa) da sua aplicação ou serviço.

Você Nunca Ganha uma Segunda Chance…

John Gruber, autor e desenvolvedor web (de Entrevista com John Gruber) webarchive

John Gruber, autor e desenvolvedor web (de Entrevista com John Gruber) archive.is

Torne-se Defensivo

Faça Design para quando as coisas derem errado

Design defensivo, quando algo der errado, como lidar

Lembre-se:

Sua aplicação pode funcionar muito bem 90% do tempo. Mas se você abandonar seus clientes no momento emcque mais precisam, é improvável que eles se esqueçam disso.

Contexto Sobre Consistência

O que faz sentido aqui pode não fazer sentido alí

Design deve oferecer o que for unicamente necessário

Inconsistência Inteligente

Em cada tela avanço ao próximo processo

Direitos Autorais é Design de Interface

Cada palavra importa

Interface e escrita, diálogo da audiência

Uma Interface

Incorpore funções administrativas em interfaces públicas

Ser enxuto nas interfaces administrativas

Sem Interface Separada

10 código

Menos Software

Mantenha seu código o mais simples possível

Muito código complexidade em cada adição

Resolver 80% do problema original despendendo 20% do esforço é uma vitória e tanto.

Resolução dos problemas de agora

Implantações difíceis apenas se necessário

Desde o início, desenvolvemos nossos produtos ao redor do conceito de pouco software. Sempre que possível, simplificamos os problemas mais difíceis. E descobrimos que a solução para problemas mais simples não é somente mais fácil de implementar e suportar, como também de entender e usar. É tudo parte de uma estratégia para diferenciar-se dos competidores: em vez de focar-se em produtos que fazem mais, construimos produtos que fazem menos.

Negociação de trade-off, entrega e percepção de valor, tempo

NÃO existe código mais flexível do que NENHUM código!

Brad Appleton, engenheiro de software (de There is No CODE that is more flexible than NO Code!)

Complexidade não aumenta linearmente com o tamanho

Um programa de 2000 linhas requer mais do dobro do esforço de desenvolvimento que um programa com a metade do seu tamanho.

The Ganssle Group (de Keep It Small)

Otimize para Felicidade

Escolha ferramentas que estimulem e motive o seu time

Escolha da stack para produtividade, engajamento do time, paixão pela atividade

Os tipos de engenheiros que você quer

O Código Fala

Ouça quando seu código diz “não”

Requisitos enormes, péssima ideia, otimização

Martin Fowler, Cientista Chefe, ThoughtWorks (de Is Design Dead?)

Se Programadores Fossem Pagos para Remover Código…

Se programadores fossem pagos para remover código do software em vez de escrever novo código, seria muito melhor.

Nicholas Negroponte, Professor de Tecnologia de Mídia no MIT de And, the rest of the AIGA Conference story

Nicholas Negroponte, Professor de Tecnologia de Mídia no MIT de And, the rest of the AIGA Conference story

Gerencie Débitos

Pague a seu código e as “contas” de design

Débito, design ruim e código ruim, cair rápido na real

Da mesma forma que você deve regularmente colocar de lado uma parte do seu salário para impostos, regularmente coloque uma parte do seu tempo para pagar seu código e débito de design. Se não fizer isso, apenas estará pagando juros (consertando grudes) em vez de pagar o montante (e movendo-o adiante).

Abra as Portas

Publique dados para o mundo via RSS, APIs, etc.

RSS para acompanhamento de iterações internas, exemplo Basecamp, eliminação da necessidade de acessar o serviço sempre

API, side projects

11 palavras

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

Não escreva um documento de especificações funcionais

Especificações funcionais são fantasias

Especificação funcional é palavra no papel, fantasia, não realidade, aplicação real, código, design, uso

Especificações funcionais são apenas uma forma de acalmar os ânimos.

Estas especificações nunca tocam nos pontos mais críticos do projeto ou mesmo avaliam seus custos, fatores que nunca devem ser esquecidos na construção de uma grande aplicação.

Especificações funcionais apenas levam à ilusão de um acordo

O fato de um punhado de pessoas concordarem sobre alguns parágrafos de texto não implica em dizer que todos chegaram a um entendimento comum: todos podem estar lendo o mesmo texto, mas chegando a conclusões completamente diferentes. Estas diferenças inevitavelmente aparecem no decorrer do projeto:

“Espere, não era isso que eu tinha entendido.”

“Hein? Não foi assim que nós descrevemos.”

“Sim, foi isso que concordamos - você aprovou que fosse desse jeito!”

Você sabe a encrenca que é.

Especificações funcionais forçam a tomada das decisões mais importantes justamente quando se tem o mínimo de informações sobre o todo.

É normal saber-se pouco sobre qualquer coisa antes de começar a construção. Quanto mais se avança no projeto, quanto mais se usa o produto, mais se entende sobre ele. É neste ponto em que as decisões deveriam ser feitas - quando se tem mais informação, não menos.

Especificações funcionais geram excesso de funcionalidades

Perigo da especificação funcional, seguir o papel é não o consumidor

Especificações funcionais não deixarão que você evolua, mude ou rearranje

Passo a passo para substituição da especificação funcional:

Forçar o uso

Especificação serve teoria, não prática

Linus Torvalds, Criador do Linux, Sobre Especificações P1

Linus Torvalds, Criador do Linux, Sobre Especificações P1 - Archive

Linus Torvalds, Criador do Linux, Sobre Especificações P2

Linus Torvalds, Criador do Linux, Sobre Especificações P2 - Archive

12 precificação e assinatura

Amostra Grátis

Dê alguma coisa de graça

Amostra grátis, vastidão de opções, ser conhecido

fácil entrar e fácil sair

Torne assinatura e cancelamento processos indolores

Fluidez na assinatura e no cancelamento

Cancelamentos, exportação dos dados, estratégia de retenção

Coelho Bobinho, Truques são para Crianças

Evite contratos de longa duração, taxas de assinatura, etc.

Faça por merecer a receita, não use taxas

Batendo de Leve

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

Você precisa divulgar uma má notícia aos usuários - como um aumento de preços? Faça o anúncio o mais indolor possível, dando aos usuários um aviso prévio. Considere também a possibilidade de um período de bônus, isentando usuários antigos por um certo período de tempo. Estes usuários são seu ganha-pão, e é seu interesse fazê-los sentirem-se valorizados, não explorados.

13 promoção

Lançamento de Hollywood

Vá de Trailer para a Prévia para o Lançamento

Para construir euforia e antecipação, vá com um lançamento holywoodiano:

1) Trailer

2) Prévia

3) Lançamento

Trailer

Dicas, build in public, form de e-mail, formadores de opinião, hacker news, product hunt

Prévia

Lives

Lançamento

Ação

A Estrada para o Dia do Lançamento

Build in public e interesses, disparo e-mail a esses

Um Poderoso Site Promocional

Vá do Trailer para a Prévia para o lançamento

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 aspessoas à aplicação o mais rápido possível.

Weblog: Blogs mantém seu site atualizado com notícias, dicas, etc.

Cavalgue pela Onda dos Blogs

Blogar pode ser mais efetivo do que propaganda (e é muito mais barato)

CAC caro, uso do blogue

Nota pessoal: canais de redes sociais e fóruns nichados

Solicite Antecipadamente

Consiga euforia antecipada e cadastros acontecendo o mais rápidos possível

Countdown page

Promova Através da Educação

Compartilhe seu conhecimento com o mundo

Educação como promotor de evangelização

Ruby on Rails, Técnica do Amarelo que Desvanesce, Signals vs Noise

Pague Antecipadamente

Comida-Funcionalidade

Eles estão famintos por isso então sirva-os

PLG, time enxuto e uso

Monitore Seus Logs

Estude seus logs para monitorar a euforia

Monitoramento de nicho, resposta a positivos e negativos

Vendas Internas Pró-Ativas

Promova oportunidades de atualização dentro de sua aplicação

Uso de upgrade em funcionalidades não freemium, CTA, explicação e comunicação humanizada

Nome-Gancho

Dê um nome à sua aplicação que seja fácil de lembrar

Nomes fáceis

14 suporte

Sinta a Dor

Derrube as paredes entre suporte e desenvolvimento

Analogia, garçom, cozinha, desenvolvimento de software, desgin, suporte

Sem intermediário entre produto e cliente

Treinamento Zero

Use ajuda em contexto e FAQs para que seu produto não precise de um manual ou treinamento

Conceito KISS, FAQ para pontos de dúvida no próprio produto

Resposta rápida

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

Resposta rápida, direta, mesmo que sem solução, dar ouvidos

Amor áspero

Esteja preparado para dizer não a seus clientes

Produto simples, não atendimento de funcionalidades

Em Forum Afinado

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

Publique suas burradas

Coloque as más notícias lá fora e fora do caminho

Notícias ruins abertas, transparência, notícias boas, pedaços

15 pós lançamento

Um Mês para melhorias

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

Lance rápido, sentimento do meio, lançamento de novidade após

Mantenha os Posts Chegando

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

Blogue com artigo 1x por semana, melhor contato com público

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 sinal de um produto abandonado e diz que as pessoas responsáveis estão dormindo no ponto.

Melhor, não Beta

Não use “beta” como uma desculpa

Sempre beta desculpa para “imperfeição”, lançamento bom

Beta não tem Sentido

Culpe o Google, e outros, por causar problemas como esse. Agora, usuários foram treinados por um monte de desenvolvedores a achar que “beta” realmente não significa nada.

Mary Hodder, arquiteta de informação, The Definition of Beta

Bugs: cada caso é cada caso

Priorize seus bugs (e até mesmo ignore alguns deles)

Só porque descobrimos um bug em nosso produto não significa que é hora de entrar em pânico. Todo software tem bugs - é apenas um fato da vida.

Priorize seus bugs.

Quantas pessoas são afetadas?

Quão ruim é o problema?

Esse bug merece atenção imediata ou pode esperar?

O que podemos fazer agora mesmo que terá o maior impacto para o maior número de pessoas?

Algumas vezes adicionar uma nova funcionalidade pode ser mais importante para seu aplicativo do que corrigir um bug existente.

Cavalgue para Fora da Tempestade

Espere até que as reações impulsivas causadas por mudanças cessem antes de tomar uma atitude

Mudanças no produto que afetam a base, reclamações, aguarde

Fique Esperto com os Vizinhos

Assine feeds de notícias sobre seus concorrentes

Monitorar concorrentes e palavras chave feedster

Cuidado com o Monstro da Gordura

Mais maduro não precisa significar mais complicado

Fazer no produto o que é necessário, conceito de microsaas

16 conclusão

Liguem seus

Motores Feito!

Execução excepcional como diferencial

Qualquer um pode ler um livro. Qualquer um pode chegar com uma idéia. Qualquer um tem um primo que é um web designer. Qualquer um pode escrever um blog. Qualquer um pode contratar alguém para grudar algum código.Qualquer um pode ler um livro. Qualquer um pode chegar com uma idéia. Qualquer um tem um primo que é um web designer. Qualquer um pode escrever um blog. Qualquer um pode contratar alguém para grudar algum código.

A grade diferença é a execução

Para software, isso significa fazer um monte de coisas certas. Você não pode somente ter uma boa escrita mas falhar em entregar as promessas na sua prosa. Design limpo de interface não vai dar certo se seu código é cheio de gambiarras. Uma grande aplicação não vale nada se promoção pobre significa que ninguém saberá sobre ela. Para pontuar grande, precisa combinar todos esses elementos.