Aplicativos em PHP/InteligênciaEmocional/Resumo do Livro Caindo na Real
|
Este módulo precisa ser revisado por alguém que conheça o assunto (discuta). |
2.8 - Resumo do Livro "Caindo na Real"
[editar | editar código-fonte]O que é Caindo na Real?
Quer construir uma aplicação web de sucesso? Então é hora de Cair na Real. Caindo na Real é o menor, mais rápido e melhor caminho para construir software.
- Caindo na Real é sobre pular todas as coisas que 'não' * representam a realidade (cartas, gráficos, caixas, setas, esquemas, wireframes, etc.) e realmente construir a coisa real.
- Caindo na Real é menos. Menos massa, menos software, menos funcionalidades, menos papéis, menos tudo que não é essencial (e a maioria do que você pensa ser essencial realmente não é).
- Caindo na Real é permanecer pequeno e ser ágil.
- Caindo na Real inicia com a construção da interface, ou seja, as telas reais que as pessoas irão utilizar. Começa com as experiências reais dos clientes, construindo a partir disso para trás. Dessa forma você obtém a interface adequada antes de obter um software errado.
- Caindo na Real é sobre iterações e baixar os custos da mudança. Caindo na Real tem tudo a ver com lançamento, refinamento e melhorar constantemente, o que o torna o caminho perfeito para software baseado em web.
- Caindo na Real entrega exatamente o que os clientes precisam e elimina qualquer coisa que não precisam.
* adicionei por considerar que faltava
Os benefícios de Caindo na Real
Caindo na Real entrega melhores resultados porque o força a lidar com os problemas reais que está tentando resolver em vez de suas idéias sobre esses problemas. Ele o força a lidar com a realidade.
Caindo na Real pula especificações funcionais e outras documentações transitórias em favor de construir telas reais. Uma especificação funcional é para inglês ver, uma ilusão de um acordo, enquanto uma página web pronta é realidade. É isso que seus clientes irão ver e usar. É isso que importa. Caindo na Real o leva lá mais rápido. E isso signfica que está tomando decisões de software baseado na coisa real em vez de noções abstratas.
Finalmente, Caindo na Real é a maneira que se encaixa idealmente para software baseado em web. O modelo convencional de entregar software em uma caixa e então esperar um ano ou dois para entregar uma atualização está desaparecendo. Diferente de software instalado, aplicações web podem evoluir constantemente de maneira diária. Caindo na Real abre essa vantagem por tudo que ele vale.
Como Escrever Software Vigoroso
Escrita vigorosa é concisa. Uma sentença não deve conter palavras desnecessárias, um parágrafo não deve conter sentenças desnecessárias, pela mesma razão que desenhar não deve ter linhas desnecessárias e uma máquina não deve ter partes desnecessárias. Isso requer não que o escritor torne todas as sentenças curtas ou evite todos os detalhes e trate os assuntos apenas em ítens, mas sim que cada palavra fale. --De "Os Elementos de Estilo" de William Strunk Jr.
Números de versão? Jogue pela janela. Você precisa construir, lançar e refinar. Então recomece e repita.
Acreditamos que software é muito complexo. Funcionalidades demais, botões demais, coisa demais para aprender. Nossos produtos fazem menos do que a concorrência -- intencionalmente. Construímos produtos que funcionam de forma mais esperta, que parecem melhor, que lhe permitem fazer suas coisas e são mais fáceis de usar.
O primeiro passo é quebrar em pequenas unidades. Quando existem pessoas demais envolvidas, nada acontece. Quanto mais enxuto você for, mais rápido – e melhor – as coisas acontecem.
Lance menos funcionalidades, mas de qualidade. Você não precisa usar a forma big bang com todo novo lançamento e amontoados de funcionalidades. Dê aos usuários pedaços minúsculos que eles possam digerir.
Construa software para você mesmo
Uma grande maneira de escrever software é começar resolvendo seus próprios problemas. Você será o público-alvo e saberá o que é importante e o que não é. Isso lhe dá um bom adiantamento na entrega de um produto fora de série.
A chave aqui é entender que não está sozinho. Se estiver tendo problemas, é provável que centenas de milhares de outras pessoas estão no mesmo barco. Esse é seu mercado. Não foi fácil?
Basecamp se originou em um problema: como uma empresa de design precisávamos de uma maneira simples de comunicar nossos clientes sobre os projetos. Começamos fazendo isso através da extranet dos clientes, que atualizávamos manualmente. Mas modificar o HTML na mão toda vez que o projeto precisava ser atualizado simplesmente não estava funcionando. Esses sites de projetos sempre pareciam ficar travados e eventualmente eram abandonados. Era frustrante porque nos deixava desorganizados e deixava os clientes no escuro.
Então começamos a procurar outras opções. Ainda assim cada ferramenta que encontrávamos ou 1) não fazia o que precisávamos ou 2) era gorda de funcionalidades que não precisávamos – como cobrança, controles estritos de acesso, planilhas, gráficos, etc. Sabíamos que deveria haver uma maneira melhor então decidimos construir nossa própria.
Quando resolvemos nossos próprios problemas, criamos uma ferramenta que nos apaixona. E paixão é a chave. Paixão significa que realmente a usaremos e cuidaremos dela. E essa é a melhor maneira de fazer os outros se sentirem apaixonados sobre ela também. Arranhando sua própria coceira
O mundo de Código Aberto abraçou esse mantra há muito tempo – eles chamam de “arranhando sua própria coceira”. Para os desenvolvedores de código aberto, significa que terão as ferramentas que querem, entregues da maneira que querem. Mas os benefícios vão mais a fundo.
Como designer ou desenvolvedor de uma nova aplicação, você precisa encarar centenas de micro-decisões todos os dias: azul ou verde? Uma tabela ou duas? Estática ou dinâmica? Abortar ou recuperar? Como tomamos essas decisões? Se é algo que reconhecemos como importante, poderíamos perguntar. O resto, chutamos. E todos esses chutes constroem um tipo de débito em nossas aplicações – uma rede interconectada de coisas que assumimos.
Como um desenvolvedor, detesto isso. O conhecimento de todas essas bombas-relógio em pequena escala nas aplicações que escrevo somam-se ao meu stress. Desenvolvedores de código aberto, arranhando suas próprias coceiras, não sofrem isso. Porque eles são seus próprios usuários, eles sabem a resposta correta para 90% das decisões que precisam tomar. 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
Você precisa de importar sobre isso
Quando você escreve um livro, precisa de mais do que uma história interessante. Precisa ter um desejo de contar a história. Precisa investir pessoalmente de alguma maneira. Se vai viver com alguma coisa por dois anos, três anos, o resto de sua vida, precisa se importar sobre isso. ""Precisa sentir paixão"". —Malcolm Gladwell, autor (de Algumas Finas Fatias de Malcolm Gladwell)
Dinheiro de fora é plano B
A primeira prioridade de muitas empresas iniciantes é adquirir fundos de investidores. Mas lembre-se, se nos viramos para gente de fora para fundos, teremos que responder a eles também. Crescem expectativas. Investidores querem seu dinheiro de volta – e rapidamente. O fato triste é que dinheiro entrando nem sempre significa a construção de um produto de qualidade.
Atualmente não é preciso muito para começar. Hardware é barato e uma boa parte de grandes softwares de infra-estrutura são código aberto e de graça. E paixão não vem com uma etiqueta de preço.
Então faça o que puder com o dinheiro que tem em mãos. Pense muito e determine o que é realmente essencial e o que pode viver sem. O que pode fazer com três pessoas em vez de dez? O que pode fazer com R$ 40 mil em vez de R$ 200 mil? O que pode fazer em três meses em vez de seis? O que pode fazer se puder manter seu emprego e construir sua aplicação nas horas vagas?
Restrições forçam a criatividade
Dirija com recursos limitados e será forçado a contar com restrições mais cedo e mais intensamente. E isso é uma coisa boa. Restrições dirigem inovação.
Um retorno rápido é bem improvável. Então foque em construir uma ferramenta de qualidade que você e seus clientes poderão viver com por um bom tempo.
Nunca jogue mais tempo ou dinheiro em um problema, apenas diminue o escopo.
'O mais tarde é eterno, o agora está voando.'
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.
Agora, com tudo isso dito, 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. Dê uma olhada e vá em frente para sua própria visão e suas próprias idéias. 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. As pessoas conseguem ler nas entrelinhas.
Entusiasmo se manifesta prontamente, claro, mas indiferença é igualmente inesquecível. Se seu compromisso não vem com paixão genuína para o trabalho às mãos, isso se torna um vazio que é quase impossível de conciliar, não importa o quão elaborado ou atrativo é o design. —Khoi Vinh, Subtraction.com
Quanto mais enxuto for, mais fácil é para mudar
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.
'Deixe as limitações lhe guiar para soluções criativas'
Nunca há suficiente para dar a volta. Sem tempo suficiente. Sem dinheiro suficiente. Sem pessoal suficiente.
Isso é uma coisa boa.
Em vez de se desesperar com essas restrições, aceite-as. Deixe que elas o guiem. Restrições incentivam inovação e forçam o foco. Em vez de tentar removê-las, use-as em seu benefício.
Diferencie-se das companhias maiores sendo amigável e pessoal
Muitas pequenas empresas cometem o erro de tentarem atuar grande. É como se elas entendessem seu tamanho como uma fraqueza que precisa ser encoberta. Muito ruim. Ser pequeno pode realmente ser uma grande vantagem, especialmente quando isto representa comunicação.
Pequenas empresas gostam de menos formalidades, menos burocracia e mais liberdade. Menores empresas são mais próximas dos clientes por padrão. Isto significa que elas podem se comunicar com seus clientes de forma mais direta e pessoal. Se a empresa é pequena, pode-se usar uma linguagem familiar ao invés de jargão. Seu site e seu produto podem ter uma voz humana ao invés de soar como um zumbido corporativo. Ser pequeno significa poder falar com os clientes, e não “se submeter a eles.”
Sempre disponível
Não importa em qual negócio você está, um bom serviço ao cliente tornou-se o maior requisito que qualquer cliente estabelecerá. Nós demandamos isso dos serviços que usamos então por que com nossos clientes seria diferente? Desde o começo nós deixamos fácil e transparente para nossos clientes contatar-nos por toda e qualquer questão que tiverem. Em nosso website nós listamos um grande número de ferramentas gratuitas que redireciona para nossos celulares e nossos cartões de visita listam os números de cada um de nós. Nós enfatizamos para nossos consumidores que eles podem nos contatar a qualquer hora independente do problema. Nossos clientes apreciam esse nível de confiança ninguém jamais abusou deste serviço. —Edward Knittel, Diretor de Vendas e Marketing, KennelSource
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)
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.
Quantas vezes se encontrou travado em um único design ou elemento de código por um dia inteiro? Quantas vezes se deu conta de que o progresso que fez hoje não foi progresso real? Isso acontece quando você foca nos detalhes cedo demais no processo. Há tempo suficiente para ser um perfeccionista. Apenas faça isso mais tarde.
Não se preocupe com o tamanho da fonte do cabeçalho na primeira semana. Você não precisa empregar o tom perfeito de verde na segunda semana. Não precisa mover em três pixels o botão de “submeter” na terceira semana. Apenas coloque as coisas na página por enquanto. Então use. Garanta que funciona. Mais tarde você pode ajustar e aperfeiçoar.
Os detalhes se revelam ao se usar o que está construindo. Você verá o que precisa de mais atenção. Sentirá o que está faltando. Saberá quais crateras pavimentar porque ficará sempre caindo nelas. É quando precisa prestar atenção, e não antes.
O Diabo está nos Detalhes
Quase me cansei da atitude “entre nos detalhes imediatamente” depois de tomar algumas aulas de desenho … Se começar a desenhar os detalhes imediatamente pode ter certeza que o desenho será uma droga. De fato, você está perdendo completamente o ponto.
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. — Patrick Lafleur, Creation Object Inc. (de Signal vs. Noise)
Faça Software que tem Opinião
Seu aplicativo deve tomar partido
Algumas pessoas defendem que o software deve ser agnóstico. Dizem que é arrogante da parte dos desenvolvedores limitar a funcionalidade ou ignorar pedidos de novos recursos. Dizem que o software deve ser sempre o mais flexível possível.
Para nós isso é papo-furado. O melhor software traz consigo uma visão. O melhor software toma partido. Quando alguém usa um software, não está procurando apenas recursos, está procurando uma abordagem. Está procurando uma visão. Decida qual é sua visão e atenha-se a ela.
E lembre, se não gostarem da sua visão há um monte de outras visões por aí. Não corra atrás de quem você nunca irá contentar.
Um ótimo exemplo é o projeto original do wiki. Ward Cunningham e seus amigos deliberadamente desproveram o wiki de muitos recursos que no passado eram considerados parte indispensável da colaboração de documentos. Em vez de atribuir cada mudança do documento a uma pessoa determinada, eles removeram muito da representação visual de propriedade. Eles tornaram o conteúdo atemporal e destituído de ego. Eles decidiram que não importava quem escreveu o conteúdo ou quando ele foi escrito. E isso fez toda a diferença. Essa decisão despertou nas pessoas um senso de comunidade e foi peça-chave no sucesso da Wikipédia.
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.
'Comece com Não'
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.). Uma vez que está funcionalidade está lá, você está preso a ela. Apenas tente removê-la e veja o quão irados ficarão os clientes. Não concorde com tudo
Faça com que cada funcionalidade dê duro para ser implementada. Ponha cada uma delas à prova e mostre que é uma sobrevivente. É como no filme “O Clube da Luta”. Você deveria considerar apenas funcionalidades que estejam dispostas a ficar aguardando na porta por três dias para serem aceitas.
É por isso que você tem que começar com um não. Cada novo pedido de funcionalidade que vem até nós – ou de nós – encontra um não. Nós ouvimos mas não agimos. A resposta inicial é “agora não”. Se o pedido continua a aparecer, então sabemos que é hora de um olhar mais profundo. Somente então nós começamos a pensar na funcionalidade de fato.
E o que dizer às pessoas que reclamam quando nós não adotamos a sua idéia? Lembre-os do porque eles gostam da aplicação em primeiro lugar. “Você gosta dele porque nós dizemos não. Você gosta dele porque ele não faz outras 100 coisas. Você gosta dele porque ele não tenta agradar a todos sempre.”
Crie algo que você possa gerenciar
Deixe os clientes informarem o que é importante
Os clientes querem absolutamente tudo. Eles virão com uma avalanche de pedidos de funcionalidades. Dê uma olhada nos fóruns de nossos produtos; A categoria ‘pedido de funcionalidade’ sempre sobrepuja as com larga vantagem.
Nós vamos ouvir sobre “essa pequena funcionalidade extra” ou “não pode ser difícil” ou “não seria fácil colocar isso” ou “vai levar apenas uns segundos para inserí-la” ou “se você adicionar isso, eu pagaria o dobro” e assim por diante.
Claro que não podemos culpar as pessoas por pedir funcionalidades. Nós as encorajamos e queremos ouvir o que elas tem a dizer. A maior parte das funcionalidades que inserimos em nossos produtos começaram como sugestões de nossos clientes. Mas, como dissemos antes, sua primeira resposta deve ser um não. Então o que você faz com todos esses pedidos? Onde você os guarda? Como você os gerencia? Você não faz isso. Você apenas os lê e então os joga fora.
Sim, leia, jogue fora e esqueça-os. Pode soar como heresia mas os realmente importantes irão, com certeza, reaparecer. Esses são os únicos que você precisa se lembrar. Esses são os realmente esseciais. Não se preocupe em organizar e guardar cada pedido que aparecer. 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.
Da Idéia à Implementação
Vá do brainstorm à esboços à HTML à codificação
Aqui vai o processo que usamos para Cair na Real:
Brainstorm
Traga idéias à tona. O que este produto irá fazer? 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.
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. Nesse estágio, esses tipos de detalhe simplesmente não têm sentido. Papel de Padeiro
Esboços são rápidos, sujos e baratos e é exatamente como você quer começar. Desenhe coisas. Rabisque coisas. Caixas, círculos, linhas. Arranque as idéias da cabeça para o papel. O objetivo nesse ponto deve ser converter conceitos em designs grosseiros de interface. Esse passo é apenas sobre experimentação. Não há respostas erradas. Crie telas HTML
Faça uma versão HTML dessa funcionalidade (ou seção, ou fluxo, se for mais apropriado). Pegue algo real e publique para que todos possam ver como fica na tela.
Para o Basecamp, primeiro fizemos a tela de “postar mensagens”, então a tela de “editar mensagens” e a coisa prosseguiu daí.
Não escreva nenhum código de programação ainda. Apenas faça um protótipo em html e css. A implementação vem depois.
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.
Teste sua aplicação com uso do mundo real
Não tenha reuniões
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 email 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:
- Elas quebram seu trabalho diário em pequenos períodos, que acabam por quebrar o fluxo do trabalho
- Elas geralmente tratam apenas de palavras e conceitos abstratos, não de coisas reais (como um trecho de código ou algum detalhe do design de interface)
- Elas geralmente tratam de uma pequena quantidade de informações por minuto
- Elas quase sempre tem uma pessoa que inevitavelmente vai fazer com que todos percam o tempo com assuntos não relacionados
- O assunto principal vai embora muito facilmente
- Freqüentemente tem pautas tão vagas que ninguém tem certeza do assunto principal
- Requerem uma preparação prévia, que quase ninguém faz
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.
Trabalhe com possíveis funcionários na base do "teste antes"
Uma coisa é olhar o portfólio, curriculum, exemplo de código ou trabalhos anteriores. Outra coisa é efetivamente trabalhar com alguém. Sempre que possível, faça um “test-drive” com possíveis novos membros da equipe.
Isso significa que você pode julgar pessoas pelas ações ao invés de apenas palavras. Você pode tomar decisões com base no que realmente importa:
- Qualidade do trabalho
Muitos programadores falam bonito, mas afinam na hora do “vamos ver”. Com open source, você consegue ver com detalhes as práticas e conhecimentos de programação de uma pessoa.
- Perspectiva cultural
Programar é tomar decisões. Muitas delas. Decisões são tomadas com base na cultura, nos valores e em ideais. Veja as decisões específicas feitas por um candidato enquanto está programando e testando, e veja seus argumentos na comunidade para ver se o candidato está dentro do que a empresa espera. Se não se encaixa na empresa, as decisões podem parecer erradas.
- Nivel de paixão
Por definição, envolvimento em projetos open source requerem um nível mínimo de paixão. Se não, porque outro motivo a pessoa perderia tempo na frente de um monitor? O tamanho do envolvimento em movimentos open source mostra quanto um candidato realmente se importa com programação.
- Porcentagem de finalização
Toda a inteligência, toda a cultura e paixão não se transformam em software de valor se o candidato não consegue terminá-lo. Infelizmente, muitos programadores não terminam seus projetos. Então, procure a exceção. Contrate aquele que consegue sair pela porta e está disposto a fazer as trocas pragmáticas que o trabalho exige.
- Lado social
Trabalhar com alguém por um bom período de tempo, durante tanto as horas de stress e descontração e altos e baixos vão mostrar a verdadeira personalidade do candidato. Se alguém não tem modos ou um lado sociável, deixe-os de lado.
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.
Contrate bons escritores
Se está tentando decidir entre poucas pessoas para preencher uma posição, sempre contrate o melhor escritor. Não importa se essa pessoa é um designer, programador, marketing, vendedor ou o que for, essa habilidade leva a escrever mais efetivamente e concisamente código, design, emails, mensagens instantâneas e mais.
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.
Uma Mente Organizada
Boas habilidades de escrita são um indicador de uma mente organizada que é capaz de arranjar informação e argumentos de uma maneira sistemática e também ajudar (não fazer) outras pessoas a entender as coisas. Isso aparece no código, comunicação pessoal, mensagens instantâneas (para aqueles colaboradores de longa distância) e até esses conceitos exotéricos como profissionalismo e confiança.
—Dustin J. Mitchell, developer (de Signal vs. Noise) Escrita Clara leva a Pensamento
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 da Universidade da Geórgia (de Como Escrever mais Claramente, Pensar mais Claramente e aprender Material Complexo mais Facilmente)
Faça Design para quando as coisas derem errado
Vamos admitir: As coisa vão dar errado online. Não importa o quão cuidadoso você faça o design de sua aplicação, não importa quanto teste fizer, os clientes ainda vão encontrar problemas. Então como você gerencia essas quedas inevitáveis? Com design defensivo.
Escolha ferramentas que estimulem e motive o seu time
Um programador feliz é um programador produtivo. É por isso que nós otimizamos para felicidade e você deveria fazer o mesmo. Não escolha as ferramentas e práticas baseado simplesmente no padrão do mercado ou métricas de desempenho. Avalie os atributos intangiveis: a ferramenta foi criada com paixão, orgulho e dedicação?. Você seria feliz trabalhando neste ambiente oito horas por dia?
O Código Fala
Ouça quando seu código diz "não"
Ouça seu código. Ele oferecerá sugestões. Ele irá dizer "não". Ele lhe dirá onde ficam as armadilhas. Ele irá sugerir novas maneiras de fazer as coisas. Ele irá ajudá-lo a se manter em um modelo de menos software.
Uma nova funcionalidade está requerendo semanas de tempo e milhares de linhas de código? Isso é seu código lhe dizendo que provavemente existe uma maneira melhor. Existe uma maneira simples de codificar alguma coisa em uma hora em vez de uma maneira complicada que consumirá dez horas? Novamente, esse é seu código o guiando. Ouça.
Seu código pode guiá-lo a consertos que são baratos e leves. Preste atenção quando um caminho mais fácil emerge. Claro, a funcionalidade que é fácil de fazer pode não ser exatamente a mesma que você originalmente tinha em mente, mas e daí? Se funciona bem o suficiente e lhe dá mais tempo para trabalhar em outra coisa, é um ganhador.
Ouça
Não se preocupe com o design, se ouvir seu código um bom design vai aparecer ... Ouça as pessoas técnicas. Se eles estão reclamando sobre a dificuldade de fazer mudanças, então leve essas reclamações a sério e lhes dê tempo para consertar as coisas.
—Martin Fowler, Cientista Chefe, ThoughtWorks (de Is Design Dead?)
Abra as Portas
Publique dados para o mundo via RSS, APIs, etc.
Não tente prender seus usuários. Deixe que eles possam ter acesso a suas informações quando quiserem, da forma que preferirem. Para tal, você precisa deixar de lado a idéia de manter os dados de seus usuários trancados a sete chaves. Em vez disso, deixe que a informação flua. Garanta o acesso à informação através de feeds RSS. Ofereça APIs que permitam a terceiros construir aplicações integradas à sua. Tais atitudes tornarão a vida dos usuários mais conveniente e expandirão as possibilidades do que sua aplicação é capaz de fazer.
No passado, as pessoas acostumaram-se a pensar nos feeds RSS apenas como uma boa maneira de se agregar conteúdo de sites de blogs e sites de notícia. Contudo, os feeds são mais poderosos que isto. Eles também podem permitir ao usuário manter-se atualizado sobre mudanças internas à aplicação sem a necessidade de logar-se repetidas vezes. Através do site do Basecamp, por exemplo, o usuário pode cadastrar sua url em um agregador de RSS e assim receber notificações de mensagens de projetos, listas de tarefas e objetivos sem a necessidade de conectar-se constantemente ao site em busca de informações atualizadas.
APIs permitem que desenvolvedores construam plugins adicionais à sua aplicação, que geralmente agregam valor ao seu produto. Por exemplo, a API disponibilizada pelo Backpack foi utilizada pela Chipt Productions na construção de um widget para o Mac os X. A pequena aplicação permite aos usuários adicionar e editar lembretes, listagens de items e muito mais a partir de seus desktops. Muitos usuários apontaram o widget como uma ótima ferramenta, e alguns mesmo apontaram-no como um fator decisivo na escolha da utilização do Backpack.
Outros bons exemplos de empresas que liberaram dados como uma maneira de conseguir um ‘efeito bumerangue’:
- A API do Google Maps permitiu o surgimento de toda sorte de pequenas aplicações que recuperam dados de outras fontes (ex.: uma listagem de apartamentos) e os exibem em um mapa.
- Linkrolls oferece aos usuários exibir seus últimos bookmarks do del.icio.us em seu próprio site.
- O Flickr permite que outros negócios acessem as suas APIs comerciais, de forma a permitir aos usuários comprar livros de fotos, posters, backups em DVD e selos. “O objetivo é manter as portas completamente abertas e permitir o maior número possível de possibilidades de utilização de suas fotos”, diz Stewart Butterfield, do Flickr.
Um Widget Faz a Diferença
Quando a 37signals lançou o Backpack, há algum tempo atrás, minha primeira impressão foi… er... bem...
Ocorreu mais ou menos na época em que a Chipt Productions lançava um widget Backpack para o Sistema Operacional Tiger — que parecia interessante demais para passar despercebido — com isso dei uma segunda olhada no Backpack. O resultado? Uma grande diferença.
Hoje, sempre que uma nova idéia surge, abro o widget, digito e salvo — e pronto. Recebo algum e-mail com algo que devo fazer? Abro o widget, digito e salvo — e pronto. O widget tornou-se um tipo de bloco de notas indispensável, que instalo em todo Mac que uso. E por se tratar de uma aplicação totalmente web, não há necessidade de nenhum tipo de controle de versão ou sincronizaçao de dados — apenas a fluidez de digitar-se dados sem ter que se preocupar em saber para onde os dados foram, nem como acessá-los mais tarde. —Todd Dominey, fundador, Dominey Design (de Trying on Backpack)
Amostra Grátis
Dê alguma coisa de graça
É um mundo barulhento lá fora. Para que as pessoas o notem no meio da multidão, dê alguma coisa de graça.
Empresas espertas sabem que dar brindes é uma excelente maneira de fisgar clientes. Veja a Apple. Eles oferecem o software iTunes de graça de forma a gerar demanda para o iPod e a loja de música iTunes. No mundo offline, as lojas fazem a mesma coisa. A Starbucks diz que uma nova compra é estimulada para cada cinco amostras de bebidas que eles dão aos clientes. Nada mau.
Para nós, Writeboard e Ta-da list são aplicativos completamente grátis que usamos para colocar as pessoas no caminho para usar nossos outros produtos. Adicionalmente, sempre oferecemos algum tipo de versão grátis de todos os nossos aplicativos.
Queremos que as pessoas experimentem o produto, a interface, a utilidade do que construímos. Uma vez fisgados, eles são muito mais propensos a atualizar para um dos planos pagos (que permitem mais projetos ou páginas e dá acesso a funcionalidades adicionais como upload de arquivos e encriptação de dados com SSL). Pedacinhos
Faça pedacinhos: crie ofertas especializadas, pequenas para que os clientes mordam. Subdivida pelo menos um produto ou serviço em pedacinhos que são baratos, fáceis ou divertidos.
—Ben McConnell e Jackie Huba, autores do Church of the Customer Blog (de What is customer evangelism?)
Dê Sua Música de Maior Sucesso
Considere doar uma de suas músicas (por álbum) como download gratuito promocional para o mundo – para ser como um trailer de cinema – como o single de sucesso enviado ao rádio – a música que faz as pessoas quererem comprar sua música.
Não se preocupe com pirataria dessa música. Deixe as pessoas tocarem, copiarem, compartilharem. Tenha a confiança que, se o mundo a ouviu, irão pagar por mais. —Derek Sivers, presidente e programador, CD Baby e HostBaby (de Free Promo Track)
Um Poderoso Site Promocional
Vá do Trailer para a Prévia para o Lançamento
A melhor ferramenta promocional é um grande produto. A palavra vai se espalhar se tivermos uma aplicação que as pessoas acham realmente útil.
Ainda assim, precisamos de 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.
Sinta a Dor
Derrube as paredes entre suporte e desenvolvimento
No negócio de restaurantes, existe uma enorme diferença entre aqueles que trabalham na cozinha daqueles que estão na linha de frente lidando com clientes. É importante para ambos os lados entender e simpatizar com o outro. É por isso que escolas de culinária e restaurantes normalmente terão chefs trabalhando como garçons para que a equipe da cozinha possa interagir com clientes e ver como é realmente estar na linha de frente.
Muitas empresas desenvolvedoras de software tem uma divisão similar. Designers e programadores trabalham na “cozinha” enquanto o suporte lida com clientes. Infelizmente, isso significa que chefs de software nunca ouvem o que o cliente realmente está dizendo. Isso é problemático porque ouvir clientes é a melhor maneira de se ligar nas partes fortes e fracas do seu produto.
A solução? Evite construir paredes entre seus clientes e a equipe de desenvolvimento/design. Não terceirize o suporte a seus clientes. Faça você mesmo o suporte. Você e sua equipe inteira, devem saber o que seu cliente está dizendo. Quando seu cliente está incomodado, você precisa saber disso. Você pecisa ouvir as reclamações. Você precisa ficar incomodado também.
Na 37signals, todos os e-mails de suporte são respondidos pessoalmente pelo pessoal que realmente construiu o produto. Por que? Primeiro, isso fornece melhor suporte aos clientes. Eles estão recebendo uma resposta diretamente do cérebro de alguém que construiu a aplicação. Além disso, isso nos mantém em contato com a pessoa que usa nossos produtos e com os problemas que estão encontrando. Quando estão frustrados, nós ficamos frustrados. Podemos dizer sinceramente que “eu sinto sua dor”.
Pode ser tentador se apoiar em análises estatísticas para revelar seus pontos problemáticos. Mas estatísticas não são como vozes reais. Você precisa eliminar a maior quantidade possível de atravessadores entre você e as vozes reais de seus clientes.
As linhas de frente são onde a ação está. Vá até lá. Faça seus chefs trabalharem como garçons. Leia e-mails de clientes, ouça suas frustrações, escute suas sugestões e aprenda com elas.
Treinamento Zero
Use ajuda em contexto e FAQs para que seu produto não precise de um manual ou treinamento
Você não precisa de um manual para usar o Yahoo! ou Google ou Amazon. Então por que você não pode construir um produto que não requer manual? Se esforce para construir uma ferramenta que requer treinamento zero. Como fazer isso? Bem, como mencionamos antes, você começa mantendo tudo simples. Quanto menos complexa for sua aplicação, menos precisará ajudar as pessoas sem necessidade. Depois disso, uma grande maneira de suporte pró-ativo é usando ajuda em contexto e FAQs em potenciais pontos de confusão.
Por exemplo, oferecemos suporte pró-ativo na tela que permite as pessoas a fazer upload de seus logotipos ao Basecamp. Algumas pessoas experimentaram um problema onde continuavam vendo um logotipo antigo por causa do cache do browser. Então, próxima à área de “envie seu logotipo”, adicionamos um link a um FAQ que instruía os clientes a forçar um recarregamento de seus browsers para ver o novo logotipo. Antes de fazermos isso recebíamos 5 e-mails por dia sobre esse problema. Agora, não recebemos nenhum.
Em Fórum Afinado
Use fórums ou chats para deixar os clientes se ajudarem
Fórum e chats de grupo baseados na web são uma grande maneira de deixar clientes fazerem perguntar e ajudar uns aos outros. Eliminando o intermediário – esse é você – você fornece uma linha aberta de comunicação e economiza seu tempo no processo.
Em nossos fóruns de produtos, os clientes publicam dicas e truques, requisições de funcionalidades, histórias e mais coisas. Nós aparecemos de tempos em tempos para oferecer assistência, mas os fóruns são principalmente um lugar para a comunidade se ajudar e compartilhar experiências com o produto.
Você ficará surpreso com quantas pessoas querem se ajudar.
Original em: