

# Pessoas e cultura
<a name="people-and-culture"></a>

 Cada workload precisa de um proprietário, e muitas pessoas e equipes podem estar envolvidas no ciclo de vida de uma workload. No entanto, antes de executar uma WAFR, defina um proprietário de segmento único (STO) para a workload. 

 Essa pessoa deve ser capaz de tomar decisões e controlar o orçamento, o número de funcionários e o roteiro. Exemplos dessa função são proprietário de produto, gerente de produto, arquiteto-chefe ou gerente de engenharia. 

 Em última análise, essa função será responsável se a workload não funcionar mais conforme o esperado. 

 É importante executar uma WAFR com um STO para melhorar seus resultados. Por exemplo, você pode encontrar itens de melhoria para a workload, mas não ter tanto êxito ao priorizá-los no roteiro do produto. Ou você pode ter dificuldade para adquirir fundos ou recursos para realizar o trabalho. 

 Geralmente, o resultado disso é uma lista de itens pendentes irrealizáveis. O STO ajuda você a evitar isso, pois ele é o responsável pela WAFR e investe no processo. 

![Proprietário de segmento único](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/userguide/images/STO.png)


## Partes interessadas necessárias
<a name="required-stakeholders"></a>

 O STO não consegue responder a todas as perguntas. Muitas pessoas e equipes estão envolvidas na arquitetura, no desenvolvimento, na proteção ou na operação de uma workload. Dependendo da organização e do tamanho da workload, o número de partes interessadas e equipes envolvidas varia. 

![Diagrama da estrutura da equipe mostrando um proprietário de segmento único acima dos participantes sugeridos da WAFR.](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/userguide/images/WorkloadTeam.png)


 Considere as seguintes perguntas sobre as partes interessadas: 

1.  Quem precisa estar presente para responder a cada categoria de perguntas? 

1.  Quais partes interessadas devem estar presentes durante quais partes da WAFR? 

1.  Como você pode informar as diferentes partes interessadas com antecedência sobre as questões? 

## Patrocinadores do pilar
<a name="pillar-sponsors"></a>

 O Well-Architected Framework é baseado em [seis pilares](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html): Embora definir um STO seja crucial, é igualmente importante conseguir o apoio de patrocinadores ou defensores específicos de cada pilar para acelerar e aumentar o valor do processo de WAFR. 

![Diagrama da estrutura da equipe mostrando um proprietário de segmento único acima de seis defensores específicos de cada pilar.](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/userguide/images/Champions.png)


 Defina patrocinadores ou defensores de pilar que possam: 
+  Atender a partes específicas da WAFR para fornecer informações ou orientações. 
+  Responsabilizar-se pelos resultados da área que eles dominam. 
+  Definir, influenciar e comunicar mudanças estratégicas interorganizacionais. 

 Sua organização tem um centro de excelência de nuvem ou uma comunidade de prática em nuvem? Comece pequeno e crie um grupo de pessoas com ideias semelhantes que possam se apoiar mutuamente com discussões e melhorias de integridade da arquitetura. 

## Criar um espaço seguro
<a name="create-a-safe-space"></a>

 Desenvolver uma cultura organizacional saudável é essencial para promover discussões saudáveis e produtivas sobre escolhas tecnológicas. As pessoas envolvidas na WAFR podem ser novas ou antigas em relação à workload em questão, ter diferentes níveis e tempos de serviço ou estarem envolvidas como parceiros e terceiros. É fundamental promover uma conversa saudável e respeitosa sobre a workload para aumentar a probabilidade de melhorias duradouras e úteis. 

 Estabeleça uma intenção positiva desde o início e enfatize-a novamente para manter o alinhamento e se concentrar na descoberta de oportunidades de melhoria. A tecnologia e as práticas recomendadas evoluem; portanto, uma WAFR deve ser estruturada como uma oportunidade de descobrir melhorias. 

 Uma WAFR não é uma auditoria. Embora as descobertas possam ajudar você a atender a diferentes padrões de conformidade, o processo não existe para “atribuir uma pontuação” a uma workload. Concentre-se em aumentar a integridade da arquitetura. 

 Uma WAFR é uma chance para perguntar “onde estamos?” e para capturar uma visão pontual da workload. Em seguida, você pode usar as descobertas para tomar uma decisão embasada e responder à pergunta “para onde devemos ir?”. 

 O processo de aprimoramento da arquitetura é uma jornada orientada pela AWS Well-Architected. Considere as seguintes perguntas ao iniciar seu processo de WAFR: 

1.  Por que você está executando a WAFR? 

1.  O que você espera conseguir com isso? 

1.  Como essa experiência beneficiará todos os envolvidos? 

1.  Onde você está agora e aonde você quer chegar? 

## Recursos
<a name="resources-1"></a>
+  [Publicação de blog sobre responsabilidade](https://aws.amazon.com/blogs/enterprise-strategy/two-pizza-teams-are-just-the-start-accountability-and-empowerment-are-key-to-high-performing-agile-organizations-part-2/) 
+  [Equipes de duas pizzas da Amazon](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/) 