Então você está criando um novo site ou loja online, e você precisa de um desenvolvedor web. Você pode precisar deles para desenvolver um site a partir do zero. Ou talvez você só precise deles para resolver alguns ajustes, alterações, problemas ou funcionalidades extras.
De qualquer maneira, seu relacionamento com seu desenvolvedor da Web pode ser difícil de gerenciar. Eu sou um desenvolvedor, então eu sei que existem tantas maneiras que o relacionamento pode desmoronar:
- Prazos perdidos
- Falta de comunicação
- Comunicação lenta
- Sem comunicação
- Over-promises do desenvolvedor
- Desenvolvedor sub-entrega
- Desenvolvedor desaparece
- Escopo vagamente definido
- Falta de protocolo para pequenas suposições / decisões
- Erros ou problemas não são corrigidos
Praticamente todo designer com quem trabalho compartilhou uma história de terror envolvendo uma dessas coisas. Para evitar ser uma história de terror, desenvolvi uma lista útil de itens de discussão pré-kickoff para nos ajudar a evitar esse tipo de problema.
Antes de entrarmos nisso, vamos ser claros: isso não é uma cura para todos os relacionamentos entre designers e desenvolvedores. No final do dia, ainda é um relacionamento humano – é complicado. Mas descobri que uma conversa aberta sobre esses itens pode iniciar um projeto com o pé direito.
1. Como nos comunicaremos?
Como você vai se comunicar enquanto trabalha no projeto? Folga? Telefonemas? Textos Emails Software PM? Tão importante quanto: com que frequência você se comunica? Todo dia? Uma vez por semana? No início, e depois não novamente até o controle de qualidade? Se você está fazendo um check-in diário, será um e-mail de duas frases ou um telefonema de 15 minutos? Qual é o plano em caso de emergências?
Mais comunicação nem sempre é igual a uma melhor comunicação
Não há respostas erradas aqui, desde que você estabeleça expectativas no começo. Mas lembre-se: mais comunicação nem sempre é igual a uma melhor comunicação.
Por que isso importa
Você quer ter um bom relacionamento com o seu desenvolvedor, e para conseguir isso, você precisa de um modo de comunicação estabelecido. Normalmente, um telefonema é útil para desenvolver uma conexão pessoal inicial e para garantir que ela seja uma boa opção de personalidade.
Durante o desenvolvimento, trabalhe para encontrar um equilíbrio entre o check-in excessivo e o insuficiente. Demais e você é micro-gerenciador. Muito pouco e o desenvolvedor pode não ficar no caminho certo. É melhor definir as expectativas no topo e cumpri-las.
2. Como você vai gerenciar o projeto?
Onde estão os arquivos e as credenciais de login que o desenvolvedor precisará? Onde você rastreará tarefas, marcos e prazos? Qual software você vai usar? Campo de base? Trello? Asana? Uma planilha ou o Google Doc? Basicamente, defina o hub central para tudo relacionado ao projeto.
Por que isso importa
Durante o projeto, o gerenciamento e a comunicação do seu projeto devem ser centralizados e rastreáveis. Muito tempo pode ser perdido na procura de arquivos, check-ins, atualizações, progresso, questões, decisões, etc. É por isso que é importante estabelecer onde o desenvolvedor pode encontrar tudo o que precisa.
3. Quem está chamando os tiros?
Você é o tomador de decisão final do projeto? Existe uma equipe de UI / UX envolvida? Existe mais alguém que tenha sugestões sobre decisões? Existe uma equipe de marketing ou um gerente que queira avaliar as decisões? Alguém mais do que você vai dar direção diretamente ao desenvolvedor? Quando o cliente entra e quantas decisões o cliente faz? O cliente terá comunicação direta com o desenvolvedor?
Por que isso importa
Você não quer recuar no desenvolvimento ou fazer com que seu desenvolvedor refaça o trabalho. Para evitar isso, é importante que todas as partes interessadas estejam cientes de todas as decisões relevantes – e que cada decisão seja registrada em um único local central.
4. Como o desenvolvedor deve lidar com suposições e pequenas decisões?
Quanta liberdade o desenvolvedor tem ao interpretar designs? Eles devem construir o site pixel-perfect de acordo com os projetos, ou devem fazer pequenas suposições em torno da consistência e reutilização de seções? Se você criou um site responsivo, você projetou todos os pontos de interrupção? Você forneceu notas sobre animações, transições e efeitos de foco? Você criou estados de validação para campos? (ou seja, os popups: “Senha inválida” ou “O nome de usuário não existe”.) Se você não o fez, o desenvolvedor está livre para tomar decisões ou sugestões?
Por que isso importa
Com muita frequência, os projetistas ficam insatisfeitos quando um site não corresponde exatamente aos designs – ou, inversamente, quando o site acompanha muito de perto os projetos, em detrimento de seu desempenho ou da linha do tempo do projeto. No início, defina seu nível de detalhes pretendido. Isso contribui para um processo de QA muito mais suave.
5. Qual é a linha do tempo?
Qual é o prazo difícil para o projeto e qual é o prazo mais curto? Há um grande sucesso de imprensa acontecendo que o site precisa ser lançado? Se o prazo for ambicioso, existe uma maneira de lançá-lo em fases? Qual é a expectativa de responder a mudanças rápidas? Uma semana reviravolta? Menos de uma hora?
Por que isso importa
realmente não ajuda a criar prazos rígidos artificiais … a honestidade é a melhor política
Se houver um prazo difícil, informe o desenvolvedor e certifique-se de deixar tempo para o teste adequado. Depois que o site for lançado, saiba que a maioria dos desenvolvedores não pode ficar de plantão a qualquer hora para fazer alterações. Esperar que um desenvolvedor faça uma correção pode ser frustrante, mas mesmo pequenas solicitações exigem manutenção do controle de versão, inicialização do ambiente de desenvolvimento, conexão ao servidor, implantação no site de produção, etc. Determine com antecedência quanto tempo você espera correções e alterações tomar e fazer um balanço do nível de prioridade de cada tarefa.
Além disso, realmente não ajuda a criar prazos rígidos artificiais. Apenas seja transparente com o seu desenvolvedor e confie neles para entregar de acordo. Mais uma vez, você está construindo um relacionamento aqui. Honestidade é a melhor política.
6. Qual é a estrutura do escopo, contrato e estrutura de pagamento?
Qual é a taxa do projeto? Qual é o benchmark para o final do projeto? O que está incluído no escopo do projeto? Quando sai o pagamento? Você está contratando o desenvolvedor para fazer o projeto a uma taxa horária ou fixa?
Por que isso importa
A última coisa que você quer é que um desenvolvedor obtenha um site a 95% do caminho e não inicie o projeto devido a uma discrepância no escopo / contrato / pagamento.
Conclusão
No geral, estabelecer expectativas e comunicação são as coisas críticas aqui. Pode parecer um pouco bobo discutir como você vai conversar um com o outro durante um projeto, especialmente se você já tem um bom relacionamento. Mas é sempre bom definir as expectativas com antecedência, para que você não termine dentro de si mesmo uma história de terror.