Esse texto é continuação, veja a parte anterior aqui
O princípio de “Seis”
Considerando que a fase de julgamento e desenvolvimento inicial foi realizada por um grupo pequeno, ficou claro que as abordagens de gerenciamento de projetos não seria função de uma equipe tão reduzida. Como resultado, uma abordagem semelhante à SCRUM foi implementada: os desenvolvedores trabalhariam em um espaço aberto, interagindo continuamente, assim eles prontamente poderiam abarcar todos os aspectos do processo de desenvolvimento. Essa foi a forma como trabalhou a equipe de desenvolvimento do “Seis”.
Definição: SCRUM
SCRUM é uma abordagem de gestão de projetos para o desenvolvimento de software ágil e dinâmico. Está baseada no princípio de que o cliente (usuário) não sabe exatamente o que precisa e poderia alterar a exigência no decorrer do processo. Isso significa que o processo de desenvolvimento é caracterizado pela presença de ciclos consequentes e numerosos: construção, demonstração, análises de respostas e, finalmente, atualização da versão.
Mas a distribuição de papéis SCRUM mudou de maneira significativa. Eugene Kaspersky definiu seis funções principais:
arquiteto
É a pessoa (ativamente envolvida no processo de codificação) que sabe o que construir e como construí-lo.
designer técnico
Não existe uma definição simples para este papel, mas é a pessoa é responsável por tornar realidade algumas ideias e soluções. Talvez o mais importante é que o designer técnico deve saber como não fazer as coisas.
inventor
O inventor aplica soluções não convencionais para resolver problemas. No caso de “Seis”, os problemas eram incontáveis. A solução tinha que, finalmente, fornecer o mais alto nível de proteção ao usuário e ainda consumir a menor quantidade de recursos do sistema.
gerente de projetos
O papel do gerente de projetos em SCRUM não pressupõe estritamente seguir regras estabelecidas. Ele controla o conjunto de recursos e prazos, mas ele não é um chefe. Ele não comanda os programadores sobre o que fazer, mas motiva-os a tomar decisões e fazer bem o trabalho.
“A equipe era pequena, não tínhamos um chefe”, diz Doukhvalov. “O gerente de projetos estava planejando, relatando, mas as decisões eram tomadas conjuntamente”.
gerente de marketing
O produto é criado para os clientes e não para a própria equipe de desenvolvimento. É vital ter uma compreensão das expectativas dos usuários com o novo produto e como eles vão utilizá-lo. Se os especilistas se ocupam de todos os aspectos técnicos do produto antivírus, é necessário também pensar em outros detalhes como definir as opções de configuração, as mensagens e criar uma interface de usuários intuitiva. Todas as características levam em consideração as necessidades dos usuários e o gerente de marketing se ocupa de entender estas necessidades.
psicólogo
Trabalhar sob pressão, dormir pouco, conflitos no grupo, a instabilidade … É necessário alguiém que crie um ambiente amigável e produtivo. Esta função foi atribuída ao próprio Eugee Kaspersky, que proporcionava à sua equipe apoio e recursos e também os protegia de influências externas.
Francamente, nos projetos SCRUM, existe outro papel fundamental: o de quem se ocupa em anotar tudo o que ocorre durante o processo de desenvolvimento. Mas esta posição não foi ocupada por ninguém e isso gerou problemas.
“Nós não sabemos o por quê, mas introduzimos este papel apenas um ano atrás”, afirma Kaspersky.
De acordo com o princípio, o número de papéis não corresponde necessariamente ao número de membros da equipe. Um papel pode ser distribuído entre várias pessoas, enquanto que um único integrante pode executar várias funções.
“Enquanto tínhamos uma organização formal, agimos como uma única equipe, por isso não havia distinção exata entre os papéis: em particular, tudo se misturava durante as sessões de brainstorming”, confessa Nikolay Grebennikov. “Por exemplo, uma pessoa que se ocupava de criar os códigos poderia expressar sua opinião sobre o desenho do aplicativo e esta opinião era levada em consideração. Eu era o gerente de projetos, mas participava ativamente dos debates. O sucesso do projeto se deve a esta flexibilidade, porque todos juntos nos preocupavámos com cada detalhe”.
De acordo com De-Monderik, os papéis eram altamente intercambiáveis: “Cada membro da equipe foi o melhor em seu domínio, mas o 50% de suas habilidades coincidiam com outra pessoa da equipe. Mike poderia se ocupar dos códigos de Sobko se ele não estivesse presente, os especialistas que se ocupavam da interface poderiam se ocupar de algumas tarefas de engenharia e vice-versa. Eu poderia fazer desenhos em vez de Max Yudanov e às veces Kolya Grebennikov poderia se ocupar do desenho também”.
É fundamental compreender que cada função é um estágio específico da execução do projeto. Durante a fase inicial, o arquiteto é a figura central. Logo, o inventor entra em ação durante o estágio intermediário do processo de desenvolvimento, quando os recursos são criados e desenvolvidos. E durante a última fase, a figura-chave é o gerente de projetos que tem o papel mais importane porque gerencia diferentes recursos para que toda a equipe respeite os prazos.
Em busca da perfeição
Com a abordagem SCRUM e um projeto tão ambicioso, para “Seis” não havia sido estabelecido uma lista fixa de requisitos, mas existiam especificações básicas. O produto tinha que:
- Defender o computador das ameaças em constante evolução;
- Aproveitar os recursos do PC da melhor maneira possível;
- Dispor dos componentes necessários para uma melhor escalabilidade;
- Ter componentes capazes de adaptar-se facilmente às diferentes plataformas.
Com estas características gerais, os requisitos técnicos correspondentes necessitavam de uma série de mudanças. Como resultado, o lançamento foi adiado várias vezes, mas a equipe foi capaz de desenvolver uma solução antivírus revolucionária alguns anos à frente das necessidades do mercado em geral, um resultado superior à qualquer expectativa.
Após o lançamento do Kaspersky Anti-Vírus 6.0, Maxim Yudanov, que era responsável pelo design da interface do usuário, disse: “Um dos principais diferenciais do projeto é a ausência de uma lista estabelecida de requisitos. Nós fizemos protótipos, discutimos o produto, atualizamos a lista de normas técnicas e recursos, anotamos os principais pontos que faltavam cada vez que surgiam post-its que colocavamos nas telas dos computadores e pedimos ajuda aos usuários para nos informar o que faltava no produto (quero dizer, a comunidade que testava as versões beta teste). Estou certo de que o produto final não teria sido o que é agora, se tivessemos utilizado o sistema tradicional de requisitos fixos. Se fosse o caso, teríamos criado um produto como se imaginava no início e estou certo de que, nesse caso, o produto seria menos eficaz do que o nosso produto final”.
Programação extrema
Hoje, esta abordagem não é nova. Mas há dez anos, aplicando-se este método para projetos de grande escala, foi algo revolucionário e não convencional. A principal diferença entre a chamada “programação extrema” (o termo foi amplamente usado na época, agora métodos semelhantes estão unidos sob o guarda-chuva de “desenvolvimento ágil de software”) e a abordagem CMM (que agora está praticamente extinta) encontravam-se dentro da ausência de uma lista tradicional de exigências que constituía uma referência sólida para o projeto durante os anos de desenvolvimento. O modelo CMM pode ser um caminho certo para projetos de desenvolvimento de terceiros, mas para projetos comerciais é inútil.
Nikolay Grebennikov, agora Diretor de Tecnologias de Informação da Kaspersky Lab, concorda: “Se tivéssemos que estabelecer uma série de caracaterísticas fixas sem possibilidade de fazer nenhuma mudança, não teríamos tido uma visão do que exatamente os usuários precisavam e não teríamos seu apoio. A primeira versão do produto dava um monte de problemas e para solucioná-los demoravámos muito tempo, passou mais de um ano e meio entre a versão alpha e o lançamento técnico. No mundo de hoje, não podemos perder todo este tempo, mas naquela época, foi uma experiência muito útil”.
A agenda de desenvolvimento (em russo)
Eugene Kaspersky é bastante simples sobre isso: “Quando você desenvolve inovações, prepare-se para as violações contínuas de prazo”.
Leia também:
O antivírus que mudou a Kaspersky – Parte I
Tradução: Juliana Costa Santos Dias
Dicas