Defina Suas Prioridades

From The Joel on Software Translation Project

Jump to: navigation, search

Por Joel Spolsky da Fog Creek Software
Quarta-feira, 12 de Outubro de 2005
Artigo original: Set Your Priorities
Traduzido por: 201.24.84.103

Teaser

Desenvolvimento customizado é aquela névoa onde o cliente diz pra você o que construir e você, “tem certeza?”, e eles dizem sim e você faz uma especificação linda e diz “é isso que você quer?” e eles dizem sim, e você faz eles assinarem a especificação em tinta permanente, não, sangue, e eles assinam, e você constrói o que eles assinaram, pronta, precisa e exatamente, e eles olham aquilo e ficam aterrorizados e chocados, e você gasta o resto da semana lendo onde no meio do seu contrato de seguro E&O1 irá se cobrir os honorários do processo que você vai se envolver, ou simplesmente calcula o valor do acordo. Ou, se você for realmente sortudo, o cliente irá sorrir e engavetar seu código, nunca mais usá-lo e nunca mais vai te ligar.

Artigo

Estava chegando a hora de parar de brincar com com o FogBugz 4.0 e começar a trabalhar na versão 5.0. Nós acabamos de entregar um grande service pack, consertando um zilhão de pequeníssimos bugs que ninguém iria notar (e introduzimos mais alguns novos pequeníssimos bugs que ninguém irá notar) e já era hora de começar a adicionar algumas novas funcionalidades.

No momento que estávamos prontos para começar o desenvolvimento, tinhamos idéias de melhorias suficientes para ocupar 1700 programadores por algumas décadas. Infelizmente, tudo que temos são três programadores e queríamos entregar no próximo outono, então teria que existir alguma priorização.

Antes de eu contar como priorizamos nossa lista de funcionalidades, deixe-me contar duas maneiras de como não se deve fazer isso.

Número um. Se alguma vez você se ver implementando uma funcionalidade simplesmente porque ela foi prometida pra um cliente, LUZES VERMELHAS DE PERIGO devem aparecer na sua cabeça. Se você está fazendo coisas para um cliente, ou você tem um “vendedor de canhões” a solta, ou você está escorregando perigosamente na ladeira que leva ao consultingware. E não há nada de errado com consultingware; é uma ladeira muito confortável para deslizar, mas só não é tão lucrativa quanto shrinkwrap.

Shrinkwrap é um modelo de desenvolvimento do tipo “pegue-o ou deixe-o”. Você desenvolve software, embala em plástico, e os clientes o compram ou não. Eles não se oferecem pra comprar caso você implemente mais uma funcionalidade. Eles não ligam pra você pra negociar funcionalidades. Você não pode ligar para a Microsoft e dizer para eles: “ei, eu adoro a função BAHTTEXT que vocês tem no Excel para soletrar numeros em tailandês, mas eu queria usar uma função equivalente para inglês. Eu comprarei o Excel se você implementar essa função”. Isso porque, se você ligar para a Microsoft, é isso que eles irão dizer:

“Obrigado por ligar para a Microsoft. Se você está ligando com um código promocional de 4 dígitos, tecle 1. Para suporte técnico dos produtos Microsoft, tecle 2. Para licenciamento de produtos ou informações sobre os programas de licenças, tecle 3. Se você sabe com que pessoa você deseja falar na Microsoft, tecle 4. Para repetir, tecle estrela.”

Percebeu? Nenhuma das opções foi “para negociar novas funcionalidade a serem adicionadas nos nossos produtos antes de comprá-los, aperte 5”.

Desenvolvimento customizado é aquela névoa onde o cliente diz pra você o que construir e você, “tem certeza?”, e eles dizem sim e você faz uma especificação linda e diz “é isso que você quer?” e eles dizem sim, e você faz eles assinarem a especificação em tinta permanente, não, sangue, e eles assinam, e você constrói o que eles assinaram, pronta, precisa e exatamente, e eles olham aquilo e ficam aterrorizados e chocados, e você gasta o resto da semana lendo onde no meio do seu contrato de seguro E&O irá se cobrir os honorários do processo que você vai se envolver, ou simplesmente calcula o valor do acordo. Ou, se você for realmente sortudo, o cliente irá sorrir e engavetar seu código, nunca mais usá-lo e nunca mais vai te ligar.

Em algum lugar entre estes extremos está consultingware, onde você finge fazer shrinkwrap enquanto faz na verdade software customizado. Aqui está como consultingware funciona:

  1. Você está trabalhando como assalariado escrevendo código para uma empresa de sapatos, e
  2. a empresa precisa de um software de engraxar sapatos, então
  3. você desenvolve o software de engraxar sapatos em VB3, usando partes de JavaScript, Franz Lisp e um banco de dados do FileMaker rodando num Mac antigo conectado na rede via AppleScript, então
  4. todos pensam que ele é ótimo, então, como você sempre sonhou em abrir sua companhia de software e talvez ser Bill Gates ou talvez até Larry Ellison (presidente da Oracle),
  5. você compra os direitos sobre EngraxaSapatos 1.0 da sua antiga empresa e consegue um VC (investidor de risco) para começar sua própria empresa, EngraxaSapatos LLC, anunciando software de engraxar sapatos, mas
  6. nenhum de seus beta testers consegue trabalhar por causa das dependências obscuras do AppleScript e o endereçamento IP definido dentro do código, então leva um mês para instalar em cada cliente, e
  7. você tem problemas em conseguir clientes, porque seu produto é tão caro por conta dos custos de instalação, incluindo o antigo Macintosh 2ci rodando System 7, que eles tem que comprar na parte de museus de computadores do eBay, que então seus investidores começam a ficar nervosos,
  8. colocando pressão nos vendedores,
  9. que descobrem que um de seus clientes em potencial não precisa de um software de engraxar sapatos, mas realmente usaria um software para passar calças, e
  10. os vendedores, sendo vendedores, vendem a este cliente o software de passar roupas a R$100 mil
  11. e agora você gasta 6 meses escrevendo um módulo de passar roupas para este cliente, sendo que
  12. nenhum outro cliente precisará disto, de tal forma que, efetivamente,
  13. para todos os fins e propósitos você acabou de gastar um ano de VC para que você pudesse trabalhar como assalariado escrevendo código numa empresa de ferros de passar; GOTO 1.

Eu terei que recomendar fortemente para você aderir o tanto quanto possível para o lado shrinkwrap da equação. Isso porque shrinkwrap não tem custos marginais para cada cliente adicional, então você pode vender a mesma coisa repetidas vezes e conseguir muito mais lucro. Não só isso, mas você pode baixar o preço, porque você divide seu custo de desenvolvimento por um número muito maior de clientes, e baixando o preço consegue-se mais clientes porque mais gente irá repentinamente achar que seu software (agora) barato vale a pena, e a vida é boa e tudo é doce.

Assim, se você se vir implementando uma funcionalidade simplesmente porque ela foi prometida para um cliente, você está deslizando para o terreno de consultingware e desenvolvimento customizado, que é um mundo bom para você estar se você gosta disso, mas simplesmente não tem o potencial de lucro de um software comercial pronto.

Agora, eu não estou dizendo que você não deve ouvir seus clientes. Pessoalmente eu penso que já é hora da Microsoft realmente implementar uma versão da função BAHTTEXT para aqueles que como nós ainda não se juntou a economia global e aprendeu Tailandês, e ainda escreve cheques utilizando outras moedas.

E, de fato, se você quer dizer a si mesmo que a melhor maneira de alocar seus recursos de desenvolvimento é efetivamente deixar seus clientes “darem lances” pelas funcionalidades, bem, você pode fazer isso também, embora você descubra que o tipo de funcionalidades que os clientes grandes e ricos querem não são os mesmos tipos de funcionalidades que o mercado em geral quer, e aquela funcionalidade que você introduziu para lidar com a moeda Baht não está realmente ajudando a vender o Excel para SPA's em Scottsdale, Arizona, e de fato o que você está fazendo é deixar sua força de venda intermediar seus desenvolvedores com o único objetivo de maximizar suas comissões Quanto ao caminho para ser Bill Gates, este não é ele.

Agora, deixe-me te contar sobre a segunda maneira de como não decidir quais funcionalidade implementar. Não faça coisas somente porque estas são inevitáveis. Inevitabilidade não é uma medida grande o bastante. Deixe-me explicar.

Em algum momento durante o primeiro ano de operações da Fog Creek, eu estava preenchendo alguns papéis, e cheguei a conclusão que eu não tinha pastas azuis.

Agora, eu tenho um sistema. Pastas azuis para clientes. Pastas verdes para empregados. Pastas vermelhas para recibos. Todo resto é amarelo. Eu precisava de pasta azul e não tinha mais. Então eu disse para mim mesmo, “Que diabos, eu eventualmente vou precisar de uma pasta azul de qualquer jeito, então eu deveria ir na papelaria e comprar algumas agora.”

O que foi, claro, uma perda de tempo.

De fato eu pensei sobre isso depois, e descobri que por um bom tempo eu tenho feito coisas bestas (este é um termo técnico), simplesmente porque eu assumo que eventualmente vou ter que ter aquilo feito, então eu deveria fazê-lo agora.

Eu usava essa desculpa para arrancar as ervas daninhas do meu jardim, tapar os buracos das paredes ou ordenar meus discos da MSDN (por cor, linguagem e número) etc etc, quando eu deveria estar escrevendo código e vendendo código, as únicas duas coisas que uma empresa nova realmente precisa.

Em outras palavras, eu me vi fingindo que todas as tarefas não opcionais eram igualmente importantes e, então, já que elas eram mesmo inevitáveis, elas poderiam ser feitas em qualquer ordem. Ta dá! Mas para ser honesto, eu estava somente deixando as coisas pra mais tarde.

O que eu devia ter feito? Bem, como empresa nova, eu podia superar meu fetiche e ter fichas todas da mesma cor. Isso simplesmente não faz nenhuma diferença. Você não precisa diferenciar seus arquivos por cores.

Ah, e os CD´s do MSDN? Jogue todos numa grande caixa. Perfeito.

Mais importante, eu devia saber que o “importante” não é algo binário, e sim analógico. Existem vários graus de importância e se você tentar fazer tudo, você não vai finalizar nada. Então se você quer as coisas feitas, você tem que entender numa certa altura qual é a coisa mais importante para ser feita no momento e que se você não está fazendo ela, você não está progredindo da maneira mais rápida possível.

Pouco a pouco, eu estou diminuindo minha tendência a adiar as coisas. Estou fazendo isso permitindo que as coisas menos importantes fiquem por fazer. Existe uma simpática senhora da companhia de seguros que me incomodou por dois meses para conseguir alguns dados que ela precisava para renovar nossa apólice, e eu não dei os dados até ela pedir pela quinquagésima vez, junto com um alerta que nosso seguro ia expirar em três dias. E isso é uma coisa boa, eu acho. Eu cresci pensando que deixar sua mesa limpa é provavelmente um sinal de que você não está sendo efetivo.

How's that for a mortifying thought!

Então. Não faça funcionalidade baseado no que seus vendedores prometeram inadvertidamente para um único cliente, e não faça funcionalidades menores/sem importância/divertidas primeiros porque você vai “precisar fazê-las eventualmente mesmo”.

De qualquer modo, de volta ao assunto da escolha das funcionalidades para o FogBugz 5.0. Aqui está como nós fizemos a primeira priorização.

Primeiro, eu comprei um conjunto de cartões de 20x12cm, e escrevi uma funcionalidade em cada um. Então eu reuni a equipe. Na minha experiencia isso funciona para até 20 pessoas, então uma boa idéia seria ter diferentes perspectivas na sala: programadores, projetitas, pessoas que falam com os clientes, vendedores, gerentes, documentadores, testadores e até (!) clientes.

Eu pedi a todos para trazer sua própria lista de idéias de funcionalidades para a reunião, também. A primeira parte da reunião foi passar por cada funcionalidade e ter certeza que tínhamos um entendimento comum sobre o que ela era, e que cada funcionalidade estava num cartão.

Neste ponto, a idéia não era debater cada uma em seus méritos, ou projetá-la, ou mesmo discutí-la: somente ter uma idéia vaga do que ela era. Algumas das funcionalidade para o FogBugz 5.0 eram algo como:

  • Home page personalizável
  • Cronogramas de software simples
  • Rastrear tempo “cobrável”
  • Dividir um bug
  • (46 outras...)

Coisas vagas. Lembre-se que não precisávamos saber neste ponto como cada funcionalidade seria implementanda, ou o que envolvia, porque nosso único objetivo era conseguir uma priorização grosseira que poderia ser usada como base para começar o desenvolvimento. Isso nos deu uma lista de cerca de 50 funcionalidades.

Na segunda parte, nós passamos por todas elas e todos votaram para cada funcionalidade: somente um “sim” ou um “não” rápido. Sem discussão, sem nada: somente um sim ou não para cada funcionalidade. Isso revelou cerca de 14 idéias que não tinham muito suporte. Joguei for todas que tiveram apenas 1 ou 2 votos, deixando a gente com 36 funcionalidades em potencial.

Depois definimos custos para cada uma dessas funcionalidades, numa escala de 1 a 10, onde 1 era uma funcionalidade rápida e 10 era uma funcionalidade monstro. Aqui é importante lembrar que o objetivo não era agendar as funcionalidades: somente separar as pequandas das médias das grandes. Só passei por cada uma delas e perguntei aos desenvolvedores por “pequena”, “média” ou “grande”. Mesmo sem saber quanto uma funcionalidade ia tomar, é fácil saber que dividir um bug é uma funcionalidade “pequena”, enquanto um vago “Home page personalizável” era grande. Baseado no consenso da estimativa de custo e meu próprio julgamento, pusemos preços para todas as funcionalidades:

Custo
Home page personalizável$10
Cronogramas de software simples$4
Rastrear tempo “cobrável”$5
Dividir um bug$$1

Mais uma vez, isso é bagunçado, não exato, e isso não importa. Você não está fazendo um cronograma hoje: você só está priorizando. A única coisa que você tem que ter aproximadamente certo é a vaga idéia de que você pode fazer duas funcionalidade médias ou uma grande ou dez pequenas com a mesma quantia de tempo. Não é preciso ser exato.

O próximo passo foi fazer uma lista de todas as 30 funcionalidades propostas e seus “custos”. Todos na equipe ganharam uma lista e $50 para gastar. Eles podiam alocar seu dinheiro onde quisessem, mas tinha apenas $50 para gastar. Podiam comprar meia funcionalidade, se quisessem, ou comprar funcionalidades em dobro. Alguém que realmente gostasse da funcionalidade Rastrear tempo “cobrável” poderia gastar $10 ou $15 nela; alguém que gostasse pouco poderia gastar $1 e esperar que outra pessoa a patrocinasse.

Em seguida, adicionamos quanto cada todos gastaram em cada funcionalidade:


CustoGasto
Home page personalizável$10$12
Cronogramas de software simples$4$6
Rastrear tempo “cobrável”$5$5
Dividir um bug$1$3

Finalmente, eu dividi a quantia gasta pelo custo:

CustoGasto
Home page personalizável$10$121,2
Cronogramas de software simples$4$61,5
Rastrear tempo “cobrável”$5$51
Dividir um bug$1$33

E então ordenei pelo número obtido para encontrar as funcionalidades mais populares:

CustoGasto
Dividir um bug$1$33
Cronogramas de software simples$4$61,5
Home page personalizável$10$121,2
Rastrear tempo “cobrável”$5$51

Tadá! A lista de todas as funcionalidades que você queria fazer, numa ordem grosseira da melhor idéia de todos sobre quais funcionalidades são as mais importantes.

E agora você pode começar a refinar. Por exemplo, você pode juntar duas funcionalidades que naturalmente podem ser juntadas, por exemplo, fazer cronogramas de software faz o tempo “cobrável” ser mais fácil, então talvez poderíamos fazer ambas ou nenhuma. E algumas vezes olhando para a lista priorizada é simplesmente óbvio que algo está bagunçado. Então, você muda! Nada está gravado em pedra. Você pode até mudar a priorização conforme você caminha no desenvolvimento.

Mas o que me surpreendeu mais é que a lista final que produzimos foi realmente uma priorização muito boa para o FogBugz 5.0, e realmente refletiu nosso consenso sobre as prioridades relativas de várias funcionalidades.

Com a lista de prioridades na mão, nós definimos o quanto de trabalho teremos mais ou menos até Março, quando planejamos parar de adicionar funcionalidades e começar a integração e fase de testes. Escreveremos especificações para cada funcionalidade (não óbvia) bem antes de implementá-la.

(Os contadores do placar do concurso de beleza entre metodologias BDUF (Big Design Up Front) e Ágeis agora devem estar profundamente confusos. “Isso foi um voto para BDUF? Ou Ágil? O que ele quer? Ele não pode tomar partido uma vez?!)

Todo o processo de planejamento tomou três horas.

Se você tem sorte o suficiente pra ter a habilidade de entregar seu software mais frequentemente que nós, você ainda precisa trabalhar em ordenar esta lista, mas não pode simplesmente parar e fazer entregas mais frequentes. A coisa boa de entregas frequentes é que você pode priorizar a lista regularmente baseado no feedback real do cliente, mas não é todo produto que pode ser dar a esse luxo.

Mike Conte me ensinou este sistema durante o planejamento do Excel 5, onde este levou duas horas mesmo com duas dúzias de pessoas numa sala de conferência. A parte legal foi que cerca de 50% das funcionalidades que não tivemos tempo de fazer eram realmente estúpidas, e o Excel estava melhor porque elas não existiam.

Não é perfeito, mas é melhor do que ir na papelaria comprar pastas azuis, isso eu te digo.

Personal tools