O Time do Windows 7

Obrigado aos que fizeram comentários ou mandaram email. Estou bem satisfeito com o diálogo que iniciamos aqui. Desde que começamos a publicar nesse blog, a energia nos corredores aqui da Microsoft tem sido simplesmente incrível. Achamos por bem começar com uma apresentação ao time de desenvolvimento do Windows. Esse artigo traz uma visão geral do time que está sendo representado nesse blog.

Mas antes de entrar no tópico principal, vamos falar um pouco mais sobre o que esperar desse blog. Gostaria de começar com uma palavrinha sobre os comentários e emails que recebi. Recebi uma quantidade enorme – a maior parto do meu final de semana foi lendo emails e comentários. Definitivamente identificamos alguns temas. Diria que a recepção ao blog foi na maior parte muito positiva e agradecemos a vocês por isso. Um dos pedidos mais populares foi discutir o desempenho do Windows e/ou como “fazer o Windows ficar mais rápido”. Temos muito que falar sobre isso, então esperamos cobrir esse tópico isso nos próximos meses. Recebemos também muitos pedidos bem específicos – freqüentemente representando lados opostos de uma questão, por exemplo, algumas pessoas falaram “por favor se livrem (ou parem de fazer) <x>” enquanto outras pessoas falaram “o que quer que vocês façam, é importante que vocês mantenha (ou façam) <x>“. Grande parte desse blog pra mim pessoalmente é discutir vários lados de um argumento. Até mesmo uma coisa que parece simples como desempenho traz muitos elementos sutis. Por exemplo, algumas pessoas sugeriram que a melhor coisa para acelerar a inicialização do sistema é não inicializar nada até que o sistema esteja ocioso. Outras pessoas sugeriram que a demora ao carregar arquivos traz uma sensação de que o computador está lento. Outros sugeriram que a melhor solução seria oferecer um “gerenciador de inicialização” que forçaria a todos os usuários a escolher o que inicializar. Todas essas abordagens têm seus méritos que merecem ser discutidos, e também provam a sutileza e ao mesmo tempo a complexidade dos pedidos mais simples.

Segundo, pra nossa surpresa, algumas pessoas questionaram a “autenticidade” do primeiro artigo. Alguns até sugeriram que os artigos estão sendo escrito por terceiros ou que esse blog é um algum tipo de complô. Estou digitando esse artigo diretamente no Windows Live Writer e clicando em publicar. Esse blog é verdadeiro – incluindo os erros de digitação e tudo. Não existe nenhum intermediário ou um processo de aprovação dos artigos. Algumas pessoas do time vão contribuir, mas não temos ninguém escrevendo artigos que não seja quem esta assinando. Usaremos apenas um nome de usuário pra todas as publicações porque facilita o gerenciamento e a segurança, mas os artigos serão assinados pela pessoa responsável pela publicação (se eu participar nos comentários, usarei meu nome no MSDN, steven_sinofsky).

Terceiro, vem a questão expectativa da freqüência de publicações e quando vamos publicar “s funcionalidades do Windows 7”. Quando falamos que vamos publicar “regularmente” demos a entender que a gente não tem uma agenda de publicação fixa e não queremos nos comprometer com uma freqüência artificial que seria inconsistente com a forma que blogs são publicados. Esperamos manter um padrão similar ao que cumprimos no IE Blog. Mas só para tranqüilizá-los, no meu blog interno ninguém nunca me acusou de não contribuir suficiente. J

Como dissemos no artigo inicial, acreditamos que vai ser interessante falar sobre o desenvolvimento do Windows 7 (o “como)” portanto o primeiro passe é estabelecer quem são os engenheiros que de fato trabalham no produto, antes de entrar nos detalhes do produto (o “por que”ou “o que”).

Então, vamos lá...

É muito simples imaginar que o time do Windows é um grupo uniforme de pessoas ou uma entidade só, e então ocasionalmente uma pessoa específica vem representar o time – algum palestrante durante uma conferência, ou autor de um livro ou artigo que ficou famoso, ou algum autor de blog. Dentro da Microsoft, o Windows é realmente um produto de toda a empresa com pessoas por toda parte contribuindo de uma forma ou de outra. O time de engenharia do Windows propriamente dito é gerenciado por mim e pelo Jon. O Jon gerencia o núcleo do sistema operacional, que representa entre outras coisas o kernel, infra-estrutura de dispositivos, infra-estrutura de rede, e as ferramentas e sistema de engenharia (tanto pra o cliente como pros servidores). Eu faço parte do grupo que desenvolve o cliente Windows, que envolve entre outras coisas a interface gráfica, área de trabalho, e suporte de mídia. Outra parte importante do produto é o Windows Media Center que é gerenciado separadamente, junto com outras tecnologias de suporte a TV digital (IPTV, extensores, etc.)

Criar uma estrutura organizacional pra um time do tamanho do Windows não é fácil, mas a parte mais importante é planejar o trabalho do time. Esse planejamento é fundamental para atingirmos nossas metas de melhoria da consistência e “unidade” do Windows 7. Então, em vez de imaginar um grupo uniforme, ou dois times, nos referimos ao time de engenharia do Windows 7 como um grupo de 25 times diferentes.

Um time de funcionalidade representa aqueles que trabalham em uma parte especifica do Windows 7 – o programa, funcionalidades, qualidade e desenvolvimento como um todo. Os times de funcionalidade representam o foco de trabalho e coordenação entre os vários times. Isso faz com que tenhamos um tamanho mais gerenciável – times de funcionalidade cabem em salas de reunião, podem ir ao cinema juntos, etc. Em media, um time de funcionalidade tem cerca de 40 engenheiros de software, mas existem times de vários tamanhos. Um time de funcionalidade tem dois aspectos importantes: o que o time faz e quem faz parte dele.

Os times de funcionalidade do Windows 7 parecem muito com as partes do Windows que vocês estão familiarizados. Tendo em vista que o Windows e uma plataforma, vários times que se mantiveram constante durante varias versões, enquanto outros são representantes de áreas mais novas com programas novos e programas que formaram a base do time. Alguns times fazem um monte de trabalho pro servidor (como o trabalho com Virtual Machines), enquanto outros tem produto final fora do Windows 7 (como o Internet Explorer).

Em geral, um time de funcionalidade inclui uma variedade de componentes e cenários que abrange todo o Windows. Recurso é uma palavra complicada, já que algumas pessoas imaginam um recurso como um elemento da interface do usuário, enquanto outras pessoas se referem a recurso como um componente da arquitetura (tipo TCP/IP). Nossa abordagem é balancear entre os cenários e arquiteturas de uma tal forma que tenhamos um nível de cobertura apropriado da experiência de ponta a ponta e também as partes da arquitetura relativas a experiência. Uma das coisas que evitamos é separar a fundação da interface do usuário. Fazemos de uma forma que os times tenham uma responsabilidade global sobre o trabalho (por exemplo, Organização e Busca desenvolve tanto o indexador como a interface de busca). Alguns dos times de funcionalidade principais do Windows 7 incluem (alfabeticamente):

• Mini-Aplicativos e Gadgets
• Tecnologias de Assistência e Suporte
• Experiência Central do Usuário
• Engenharia de Cliente e Telemetria
• Implantação e Plataforma de Componentes
• Gráficos
• Dispositivos e Mídia
• Dispositivos e Armazenagem
• Documentos e Impressão
• Sistema de Engenharia e Ferramentas
• Sistema de Arquivos
• Organização e Busca
• Fundamental
• Internet Explorer
• Internacional
• Kernel e VM
• Media Center
• Rede - Central
• Rede - Empresas
• Rede - Sem fio
• Segurança
• Plataforma de Interface do Usuário
• Plataforma de aplicativos do Windows

Acho que a maioria desses nomes é intuitiva o suficiente para o propósito desse artigo – na medida em que publicamos mais, os membros dos times de funcionalidade vão identificar qual time eles fazem parte. Isso dará ao leitor uma idéia dos subsistemas do Windows e como subdividimos um projeto enorme em partes que fazem sentido. Obviamente durante o projeto coordenamos e desenvolvemos recursos que atravessam os times de funcionalidade. É uma questão de pratica, porque freqüentemente se quer desenvolver programa em um conjunto de camadas por razões de eficiência e desempenho (digamos de baixo pra cima), mas os usuários utilizam o programa através das camadas, e Profissionais de TI podem querer gerencias de cima pra baixo. Admito que as vezes isso é uma visão muito interna já que não tem como vocês terem uma noção clara de onde as coisas residem. Por exemplo, o recurso de tablet e escrita fazem parte da plataforma de interface do usuário, juntamente com voz, reconhecimento de voz, multitouch, e acessibilidade. A razão para isso é a necessidade de compartilhar a infra-estrutura pra todos os mecanismos de “entrada” mesmo que um usuário jamais utilize todas essas camadas. Dessa forma, projetamos os APIs para gerenciamento de entrada, de uma forma tal que engenheiros de software podem se beneficiar de todas as formas de interação através de um único grupo de APIs.

Outro aspecto dos nossos times de funcionalidade é a sua composição. Um time de funcionalidade representa três disciplinas principais de engenheiros de software, engenheiros de software de testes, e gerentes de programa. A abordagem da Microsoft utilizando essas três disciplinas é ímpar e chamou a atenção de pesquisadores da área. No meu blog antigo eu descrevi engenheiros de software e gerentes de programas nos links acima, mas ainda estou devendo uma descrição de engenheiros de software especializados em teste.

Uma breve descrição dessas funções é que engenheiros de software são responsáveis pela arquitetura e programa, gerentes de programa são responsáveis pelos recursos e descrição funcional, e engenheiros de software especializados em teste são responsáveis pela validação e defesa dos interesses do cliente. Todos são responsáveis por qualidade e desempenho, cada um trás uma perspectiva diferente ao trabalho. Para cada funcionalidade, cada engenheiro de software, engenheiros de software especializado em teste, e gerente de programa trabalham como um time (literalmente e conceitualmente). Isso é importante para o “balanço de poderes” em termos de como trabalhamos e nos asseguramos de uma abordagem balanceada ao desenvolvimento to Windows 7. Organizacionalmente estamos estruturados de uma forma tal que engenheiros de software trabalham pra engenheiros de software, engenheiros de software especializados em teste para engenheiros de software especializados em teste, e gerentes de programa para gerentes de programa. Isso significa que estamos organizados ao longo dessas funções de engenharia. Isso permite duas otimizações – o foco na especialidade e no domínio e também faz com que tenhamos certeza que não estamos construindo um produto em silos, mas focados no produto como um todo.

Falamos sobre essas três disciplinas juntas porque criamos times de funcionalidade com n engenheiros de software, n engenheiros de software de teste, e 1/2n gerentes de programa. Essa proporção é constante em todos os times. Na média cada time de funcionalidade do Windows 7 tem por volta de 40 engenheiros de software.

Também temos membros do nosso time de engenharia que trabalham no produto inteiro:

• Documentação – escritores e editores que criam conteúdo de ajuda, o website, documentação de SDK, e documentação de implementação
• Planejamento de Produto – responsáveis pelas pesquisas com clientes e aprendizado que informa a seleção de funcionalidades. Planejamento de Produto também coordena o nosso trabalho com parceiros do ecossistema no que diz respeito à parceria durante o desenvolvimento da versão.
• Design de Produto– desenvolve o modelo de interação, a linguagem gráfica, e a linguagem de design do Windows 7
• Pesquisa e Usabilidade – criam estudos de campo e laboratório que mostram como produtos atuais e futuros vão desempenhar com clientes

Já falaram que o time do Windows é grande demais e que atingiu um tamanho problemático. Ao mesmo tempo, ao julgar pelos comentários existe uma demanda significativa por uma vasta quantidade de funcionalidades e mudanças no Windows. O Windows é um grande projeto e requer pessoal. A forma como avalio essa situação é que meu trabalho é deixar o time do Windows no tamanho ideal – parece clichê mas quero dizer que o time não é nem grande nem pequeno, e sim gerenciado efetivamente de uma forma que o trabalho que produzimos reflita a quantidade de pessoas que trabalham no projeto, e que os resultados sejam atingidos conforme articulados. Lembro da cena de Amadeus quando o imperador sugere que o Casamento de Fígaro contém notas demais, e o Mozart fala “existem apenas as notas musicais que são necessárias, majestade, nem mais nem menos”. Aí o imperador sugere que Mozart remova algumas notas e ele simplesmente pergunta “qual vossa majestade tinha em mente?”. Obviamente, as pessoas no time representam os recursos com os quais implementamos funcionalidades e cenários, então o desafio é ter o tamanho certo de time e uma estrutura que maximize nossa capacidade de executá-los – nem mais nem menos.

Eu prometi a mim mesmo que nenhum artigo teria mais que 4 paginas e estou chegando perto. Os comentários são ótimos e estão nos ajudando a definir artigos futuros. Espero que esse artigo comece a criar um contexto compartilhado.

--Steven