Share via


Segredos do Windows: Ship It

Quem recebe um prêmio "Ship It"? Você precisa ter contribuído para a expedição do produto real — caso contrário você está apenas escrevendo código.

Raymond Chen

Há um prêmio dado internamente na Microsoft chamado "Enviá-lo." Você recebe esse prêmio cada vez que você enviar um produto.

Um dos deveres do gerente de projeto ocultos é decidir quem é elegível para receber um prêmio navio-lo quando o produto for enviado. Para pessoas que têm trabalhado em um projeto de todo o caminho através da decisão é fácil. Para as pessoas que aderiram ou deixaram o projeto parcialmente através de, porém, a decisão não tão óbvia.

A chave para o navio-é o navio: Você tem que ter contribuído para o processo de código de envio. Para programadores, isso significa não somente as tarefas óbvias de conceber e aplicar os recursos, mas todo o trabalho que vai junto com esse processo. Aqui estão alguns exemplos:

  • Manter o código em todo o ciclo de vida do projeto.
  • Solucionar problemas de desempenho.
  • Quedas e fracassos, mesmo aqueles que não são culpa do código de depuração.
  • Passar por todos os relatórios de bugs e corrigir bugs, especialmente aqueles realmente desagradáveis que levar um mês para descobrir.
  • Revisar o código por causa de um descuido na concepção original ou um recurso mais recentes (e essas revisões podem ser extensas).
  • Decida quais partes do seu recurso a abandonar. Como Larry Osterman observa no blog engenharia Windows 7, em um post intitulado "7 de engenharia: Uma vista da parte inferior, "corte está sendo enviado. É melhor abandonar algo que não está vindo junto do que ao risco de atrasar o produto inteiro esperando indefinidamente por uma área de problema.

Um gerente sênior disse-me que depois de um projeto é concluído e ele entrega os prêmios navio-lo, ele irá ocasionalmente obter uma peça de e-mail de um membro da equipe antiga dizendo: "Ei, por que não recebi um navio que prêmio? Eu trabalhei em seu projeto até data tal e tal, e enviado meu componente no produto final."

Sua resposta é muitas vezes algo como: "Ah, sim, eu lembro de você. Você trabalhou na equipe no início, quando o céu era o limite e tudo era possível. Você escreveu um monte de código e, em seguida, você deixou. Nós ficou preso integrando-os com o resto do produto, mantendo o código, corrigir os bugs, diagnosticar problemas de desempenho, lidar com o resultado de compatibilidade de aplicativo, depuração de todos os ruídos elétricos, tudo o que outras coisas que você precisa fazer para enviar o produto. Você estava na equipe do projeto para a primeira parte, a parte onde você Gravar código."

Em outras palavras: "Você estava aqui por diversão parte do projeto, e, em seguida, quando a parte não-diversão começou, afiançado. Você comeu a sobremesa e deixou-nos com os legumes."

Você sabe quem realmente merece o prêmio navio-lo para seu componente? A pessoa que entrou para a equipe e foi dada a responsabilidade para seu código. Essa pessoa escreveu até o status relatórios para o recurso, participou das reuniões de recurso, respondeu ao e-mail de pessoas que tenham problemas para usar o recurso, depurado as falhas e bugs corrigidos, não só em seu componente, mas em vários outros componentes.

Portanto, a resposta, "por que não recebi um navio ele prêmio?" é sempre, "porque nós deu-lhe para que outra pessoa em vez disso — a pessoa que realmente enviou seu código."

O membro da equipe antiga admite tanto a mensagem original: “... e enviado meu componente no produto final." Eles admitem que alguém realmente enviado seu componente. Assim, não há nenhum prêmio navio-lo para eles. É chamado o prêmio Ship It — não o código ele award.

Adam Barr tem um bom resumo do prêmio navio-lo em seu Web site. O primeiro comentário sobre seu artigo inclui o início da história do prêmio. A controvérsia que cercou o prêmio nave-lo em sua introdução há muito que tenha morrido afastado. Agora, é apenas uma parte regular do trabalho.

 

Raymond Chen

**Raymond Chen**identicamente, intitulado livro (Addison-Wesley, 2007) e do Web site, The Old New Thing, lidar com história de Windows, programação do Win32 e como não fazer uma apresentação para um executivo.

Conteúdo relacionado