Funções que Ditigam o Ritmo do Projeto
Em um projeto Salesforce, é possível contratar um excelente arquiteto, uma equipe de desenvolvimento experiente e um gerente de projeto organizado, e ainda assim atrasar o cronograma. A razão comum não é o ritmo de construção, mas sim o ritmo da tomada de decisão. O desenvolvimento aguarda uma decisão, a decisão aguarda uma reunião, e a reunião aguarda agendamento.
Portanto, a divisão útil de papéis não é sobre quem faz o quê, mas sim sobre quem decide o quê e com qual tempo de resposta. Uma visão geral das fases em que cada função é necessária pode ser encontrada no Guia de Implementação do Salesforce.
As Nove Funções e o Mandato de Cada Uma
Executive Sponsor — Intermedeia decisões entre departamentos, aprova concessões de scope e protege a prioridade contra pressões concorrentes. Se não tiver autoridade orçamentária, não é um Sponsor, mas sim um representante.
Process Owner — Define como o trabalho será realizado na prática após a mudança, e aprova que o processo construído está alinhado com a realidade. Um para cada processo central, e não um comitê.
Product Owner / Gerente de CRM — Gerencia as prioridades no backlog, decide entre requisições concorrentes e mantém a ligação entre requisitos e valor.
Gerente de Projeto — Cronograma, dependências, riscos, coordenação de fornecedores e relatórios.
Arquiteto de Soluções — Decide sobre o modelo de dados, permissões, limites do sistema e método de implementação; responsável por documentar alternativas consideradas.
Salesforce Admin — Configuração, ambientes, gerenciamento de usuários e manutenção contínua após a implantação.
Desenvolvedor — Lógica customizada, integrações, testes automatizados.
Data Owner — Determina qual é a fonte da verdade, o que é considerado um registro válido e quem aprova o carregamento de dados.
Líder de Adoção e Treinamento — Comunicação, treinamento por função, gerenciamento de resistência e medição de uso.
Em um projeto pequeno, uma pessoa pode desempenhar duas funções, mas existem dois pares que não devem ser unificados: Arquiteto e Gerente de Projeto (conflito entre precisão e velocidade), e Process Owner e Líder de Testes (testar a si mesmo).
Quem Deve Ser Interno
| Função | Pode ser Externo | Explicação |
|---|---|---|
| Executive Sponsor | Não | Requer autoridade organizacional |
| Process Owner | Não | Requer propriedade do trabalho na prática |
| Data Owner | Não | Requer responsabilidade regulatória e de negócio |
| Product Owner | Parcialmente | É possível ter consultoria, mas não substituição |
| Gerente de Projeto | Sim | Comum e aceitável |
| Arquiteto de Soluções | Sim | Recomenda-se acompanhamento interno para conhecimento |
| Admin | Sim, temporariamente | Preferível transferir para interno antes do Go Live |
| Desenvolvedor | Sim | Padrão |
| Líder de Adoção | Parcialmente | A mensagem interna deve vir da organização |
Matriz RACI para Pontos de Decisão Centrais
| Decisão | Accountable | Consulted | Tempo de Resposta Necessário |
|---|---|---|---|
| Estrutura do Modelo de Dados | Arquiteto | Process Owner, Data Owner | Até uma semana |
| Mudança de Scope | Sponsor | Product Owner, Gerente de Projeto | Até uma semana |
| Prioridade no Backlog | Product Owner | Process Owners | Até dois dias |
| Definição de Campo Obrigatório | Process Owner | Admin | Até dois dias |
| Aprovação de Carga de Dados | Data Owner | Arquiteto | Até três dias |
| Aprovação de Go Live | Sponsor | Gerente de Projeto, Process Owner | Conforme marco definido |
| Resolução de Bloqueio Crítico | Gerente de Projeto | Arquiteto, Admin | No mesmo dia |
A coluna de tempo de resposta é a parte interessante da tabela. RACI sem um SLA para decisão é uma descrição agradável que não muda o ritmo.
Disponibilidade Real – O Erro Reincidente no Planejamento
| Função | Levantamento de Requisitos | Construção | Testes | Go Live e Semanas Pós-Go Live |
|---|---|---|---|---|
| Sponsor | Baixa, constante | Baixa | Média | Média |
| Process Owner | Alta | Média | Muito Alta | Alta |
| Product Owner | Alta | Alta | Alta | Média |
| Admin | Média | Alta | Alta | Muito Alta |
| Data Owner | Média | Baixa | Alta | Média |
| Líder de Adoção | Baixa | Média | Média | Muito Alta |
O planejamento falho comum é a suposição de que a carga do Process Owner diminui após o levantamento de requisitos. Na prática, ela aumenta novamente na fase de testes, justamente quando o funcionário retorna ao seu trabalho rotineiro.
Exemplo Ilustrativo: Faculdade Acadêmica
O cenário é hipotético e destinado à ilustração. Uma faculdade implementou um sistema de gerenciamento de candidatos. A equipe foi definida corretamente no papel, mas o "Process Owner" era o chefe do departamento de admissões que dedicava duas horas semanais ao projeto. Qualquer pergunta sobre o status do candidato aguardava até a terça-feira de manhã.
Após dois meses, foi medido que o atraso acumulado na espera por decisões superou o atraso por qualquer outra razão combinada. A solução não foi contratar mais desenvolvedores. A faculdade nomeou um vice-diretor que recebeu um mandato explícito para tomar decisões diárias até um nível de influência definido, deixando para o chefe do departamento apenas as decisões que alteravam a política. O ritmo de desenvolvimento aumentou sem mudança na equipe do fornecedor.
Modelo de Engajamento com o Fornecedor
Três mecanismos são suficientes para a maioria dos projetos:
- Diário de Decisões Conjunto — Cada decisão com data, responsável, justificativa e alternativas rejeitadas. Esta é a única documentação que permanece útil dois anos depois.
- Ponto de Contato Único de Ambos os Lados — Múltiplos contatos diretos de vários participantes com os desenvolvedores são a maneira mais segura de perder o controle.
- Ciclo de Demonstração Regular — O Process Owner vê um produto funcionando, não uma apresentação. A diferença entre a expectativa e a entrega é revelada em duas semanas, e não em dois meses.
Em grandes organizações, uma camada adicional de governança entre unidades de negócio é necessária, conforme descrito no Guia de Implementação do Salesforce em Organizações Enterprise.
Pontos de Encontro com Outras Fases
A composição da equipe é derivada diretamente de duas coisas: os produtos que são necessários na fase de levantamento de requisitos, detalhados no Guia de Descoberta de CRM, e a amplitude da primeira onda, definida pelas regras no Guia de Definição de MVP do Salesforce. Uma primeira onda mais restrita exige menos Process Owners simultaneamente, e essa é uma razão independente para limitar a amplitude.
Verificação Rápida Antes de Iniciar um Projeto
Responda a quatro perguntas com nome e sobrenome, não com o nome do departamento: Quem decide quando Vendas e Operações não concordam? Quem aprova que o processo construído corresponde à realidade? Quem diz quais dados são confiáveis? E quem manterá o sistema daqui a um ano? Uma resposta ausente para qualquer uma delas é o maior risco no projeto, e também a única que não é resolvida com dinheiro.