Get best of the week

Como a Amazon está organizada

Como muitas outras empresas dos EUA, a organização do fluxo de trabalho da Amazon é baseada em princípios básicos, cujo principal objetivo é ajudar os funcionários a tomar a decisão certa com base nos valores da empresa. Conversamos com um gerente de produto da Amazon, que falou sobre quais princípios a empresa segue, como eles ajudam nas tarefas e quais processos a equipe passa ao desenvolver um novo produto. Abaixo, deixamos um link para um vídeo com uma entrevista completa.

Missão, Visão e Princípios da Amazônia


No meu entender, a missão da Amazon é ser a empresa mais orientada para o cliente do mundo. Todos os produtos nos quais a corporação está trabalhando são desenvolvidos com o objetivo de primeiro fazer o produto para o cliente e aumentar suas vendas.

Existem 14 princípios em que uma empresa vive e são usados ​​em todos os processos de trabalho. Esses princípios são bastante básicos, não são nada de especial. Eles são orientados pelo lançamento de um novo produto, durante entrevistas ou ao dar feedback a um colega. Eles não são obrigados a memorizar, mas quando você trabalha em uma empresa, você quer, você não quer, começa a seguir esses princípios.

Muitos deles se separam. Por exemplo, como Pense grande e Viés de ação. Um diz: "Pense globalmente" e o outro diz: "Aja, não planeje". De fato, existem muitos princípios que conflitam entre si. Mas esse é o ponto. Se os funcionários se fixassem no princípio do Pense Grande, todos estariam dentro dos prazos. E se apenas o Viés de Ação fosse respeitado, eles rapidamente executariam pequenos projetos e não pensariam em grandes.

Muitos dizem que a cultura amazônica é mais exigente. As pessoas vêm aqui para trabalhar, estudar e desenvolver. E quando ficarem cansados, vá para a Microsoft.

Isso ocorre porque a Amazon é uma empresa mais dinâmica e de rápido crescimento. Estamos tentando crescer em direções diferentes. Mas o modelo de negócios da Boeing e da Microsoft não mudou por muitos anos. O Google tem a mesma coisa: o mecanismo de busca continua sendo sua principal fonte de renda.

A Amazon é incentivada a gerar constantemente novas idéias. Sempre há muitos projetos no processo de desenvolvimento. Quando o trabalho em um produto termina, todos imediatamente mudam para outro. E, ao mesmo tempo, metas altas para cada projeto são sempre definidas dentro dos departamentos.



Processo de desenvolvimento de produtos


A primeira coisa que você deve fazer antes de definir a tarefa é testar a hipótese. Para isso, MVP ou MLP é usado. Com base nesses conceitos, um documento grande é compilado, que é considerado por toda a equipe. Duas coisas devem ser destacadas no documento:

Como o projeto resolverá a questão dos clientes? O documento possui 1 página para explicar sucintamente a idéia e transmitir seu valor.

Que perguntas os consumidores podem fazer sobre o produto? E questões técnicas: como vamos monetizar? Onde comprar equipamento técnico? Quem será o contratado? Tudo deve ser descrito no documento no formato de perguntas e respostas.

Se entendermos que todos gostaram da ideia, ela entra em desenvolvimento. O gerente de produto compila uma lista de requisitos, detalhando-os no estágio de lançamento do Agile. Tudo é organizado de maneira a testar passo a passo uma coisa e obter feedback.

O mais importante da equipe é não esperar por instruções. Se você vem à tona com algum tipo de problema, já deve ter uma solução. E o gerente só pode dar feedback - se você encontrou uma boa solução ou não.

A equipe sempre tem uma programação para os dias em que será concluída. Toda semana, os funcionários se reúnem para discutir tarefas. Mostramos em um painel com os status - verde, amarelo e vermelho.

Verde significa que está tudo bem, não é necessária atenção à tarefa. Amarelo - algo deu errado, mas sabemos como corrigi-lo. Por exemplo, eles planejavam terminar o projeto até 1º de maio, mas havia um problema que tentaremos resolver até 1º de maio. E vermelho - algo deu errado, e ainda não sabemos como cumprir os prazos.

Depois disso, cada desenvolvedor mostra demos com o trabalho realizado. Durante essas reuniões, o gerente de produto tem a oportunidade de fornecer feedback e alterar o caminho da tarefa. Quanto ao resto - a oportunidade de pedir conselhos aos colegas, se não estiver claro como resolver um dos problemas. Os relatórios semanais da equipe apóiam a cultura Agile quando todo mundo está tentando lançar algo para lançamento, em vez de usar um ano inteiro.

Quando o projeto está pronto, ele é aprovado pelo gerente de produto e enviado para a próxima etapa - teste. A empresa possui testadores internos que verificam se o recurso quebra e um grupo de testadores beta que, por sua vez, dão seus comentários. Após os testes, o desenvolvimento é lançado em alguns dias. E é aí que o trabalho na tarefa termina.



Organização dos processos de trabalho na empresa


Scrum - um método de priorizar tarefas pelas próximas 2-3 semanas - para um sprint.

O Sprint é tão curto quanto você diz: “OK, nas próximas dez semanas faremos essas 10 tarefas. E trabalharemos apenas neles e nada mais. ” Isso tem seus prós e contras. Por um lado, você não se distrai com outras tarefas. Mas você precisa constantemente fazer acréscimos, e eles vão correr bastante.

Não existe tal coisa na programação que você simplesmente sentou e começou a escrever código. Primeiro, o gerente de produto coleta todos os requisitos, descreve as funções do novo produto. Então tudo vai para o design. Os programadores se sentam e descrevem o que precisam fazer com base nos requisitos, por exemplo, integrar-se ao sistema, criar uma estrutura específica etc. O terceiro estágio é o código em andamento, onde o funcionário já está sentado e começa a escrever o código. Depois testando. E a última etapa é o lançamento.

E aqui o Kanban é uma metodologia na qual você define limites para cada estágio. Um grupo de "requisitos" não pode ter mais de 3 funções. Até transferir qualquer um dos requisitos para o design, não posso adicionar novas tarefas.

Ou seja, o fluxo de tarefas é regulado. Se você tiver mais desenvolvedores, poderá expandir as tarefas. As vantagens da metodologia é que ela é flexível. A priorização negativa pode mudar constantemente, diferentemente do Scrum. A qualquer momento, você pode incluir uma tarefa que não existia antes.

Ambas as abordagens estão relacionadas à metodologia Agile. Seu significado é que você sempre divide uma versão grande em pedaços pequenos e os libera o mais rápido possível, para não fazer o que o usuário não precisa.

No Scrum, avaliamos cada tarefa em pontos. Você não pode mensurá-los com nada, é mais um valor relativo. Por exemplo, uma tarefa é 4 pontos a mais do que a tarefa estimada em 2. Esses pontos permitem ver o quanto o desenvolvedor fechou sua tarefa.
No Kanban, isso é mais complicado.

Nossa outra regra é levar apenas 3 tarefas para o trabalho. Se a equipe tiver 10 desenvolvedores, todos estão trabalhando nessas tarefas, ninguém poderá assumir uma nova. Porque se cada desenvolvedor executar uma tarefa, que leva 2 meses de tempo de desenvolvimento, haverá apenas 2 lançamentos por mês, respectivamente.

É por isso que há restrições em pelo menos três tarefas, cada uma com três desenvolvedores. Além disso, se alguém for libertado, ele não poderá assumir um novo projeto. Ele deve ajudar os colegas a concluir o restante das tarefas definidas para o sprint. E somente depois que o projeto foi lançado, você pode executar novas tarefas.

More articles:


All Articles