Guarda-corpos do projeto: projeto pelo comitê
Quando você é contratado para construir uma solução para outras pessoas – principalmente na web, já que é a área em que trabalho – acho que há uma série de fatores que são importantes para um projeto :
- Não deve haver “projeto por comitê".
- Ninguém mais que a equipe de desenvolvimento principal deve ser capaz de fornecer desenvolvimento, preparação e produção.
- Ninguém deve ser capaz de escrever para produção, exceto a equipe de desenvolvimento (e mesmo assim, deve haver um processo de implantação).
Sempre hesito em fazer declarações como essa, pois parecem dogmáticas, mas acho que quanto mais tempo trabalho nessa indústria, mais acho que essas três regras são importantes.
Ou talvez sejam apenas diretrizes. Afinal, há tiros chamados antes de realmente fazermos as coisas.
Independentemente de serem mais sugestões ou regras não importa muito. Há razões para que todos cheguemos às conclusões que chegamos, certo? E assim, nos próximos posts (em vez de um post longo), vou compartilhar as razões pelas quais considero essas três regras importantes.
Design por Comitê
Ao usar este termo, não quero dizer que uma única pessoa deva ser responsável pelo design de um site. Quero dizer apenas que uma agência ou um grupo de pessoas que se concentram no design deve ser responsável por isso.
Design por comitê é um termo depreciativo para um projeto que tem muitos designers envolvidos, mas nenhum plano ou visão unificadora.
Então, um “comitê” neste caso é quando um grupo de pessoas, ou os clientes ou aqueles relacionados aos clientes de alguma forma, vêm para ver o resultado da implementação (ou mesmo apenas o design), sugestões por e-mail do que eles gostariam gostaria de ver e esperar que isso aconteça.
Ou seja, a expertise se um determinado designer for sacrificado pelas opiniões de outro grupo.
A princesa Leia não era um comitê.
E, talvez em casos extremos (embora eu nunca tenha experimentado isso pessoalmente), use o pagamento como alavanca para conseguir o que quer.
A questão é que as pessoas contratadas para projetar a solução para o cliente devem ser, como afirmado, especialistas na área. Eles entendem tipografia, cores, resoluções de tela, acessibilidade e assim por diante.
Deixá-los para sua área de especialização é sempre uma boa ideia.
Cuidando do Projeto
Nada disso tem a ver com alguém ter mais controle sobre o projeto do que qualquer outra pessoa.
Trata-se de garantir que todas as partes interessadas do projeto estejam trabalhando em conjunto e não cruzando áreas de responsabilidade. (Imagine, digamos, os GIFs que seriam usados para publicidade se os desenvolvedores fossem responsáveis pelos comerciais. 😏)
A conclusão é que um projeto de sucesso é apenas quando todos ficam no seu canto e trabalham juntos em sua própria área de especialização.
Caso contrário, você acaba com as coisas saindo de sincronia e basicamente criando mais problemas quando não havia nenhum (bem, pelo menos em uma área específica) para começar.
Qual é o próximo?
Na próxima postagem, abordarei a ideia de ambientes de provisionamento, o que isso significa e como isso afeta o papel geral do gerenciamento de projetos. Mas vou entrar em mais detalhes sobre isso no post.
Em última análise, trata-se de garantir que quem tem acesso de leitura e gravação às várias áreas nas quais o aplicativo ou projeto pode ser implantado. Claro, para alguns que estão lendo isso, isso pode parecer um pouco como conteúdo “iniciante” ou não como conteúdo relacionado a “desenvolvimento”.
Mas se você está trabalhando com outras pessoas para construir uma solução, então essas são coisas que você provavelmente encontrará e é mais fácil ter um plano baseado nos erros que outras pessoas cometeram (ou seja, eu 🙂) do que aprender coisas o jeito difícil.