A realização de projetos de mídias digitais é altamente competitiva, dinâmica e requer dos agentes envolvidos que compreendam sua complexidade contextual e a de seus produtos, para selecionar a metodologia de gestão mais adequada a cada contexto de projeto e uso do resultado final.

A seleção da metodologia de gestão leva em conta não só as situações contextuais, comerciais e técnicas de cada produto como também os contextos de desenvolvimento que se adaptam ao estilo de liderança dos gestores do projeto e do cliente. Entre os diversos modelos disponíveis e amplamente consolidados, pode-se aplicar técnicas como:

Desenvolvimento ágil – Modelo evolutivo, com diversas variações, como XP (Extreme Programming), Scrum, Lean Programming, FDD (Feature Driven Developement), Lean Startup, Kanban. Baseia-se na auto organização flexível da equipe, para, por meio de iterações e colaboração, se adaptar rapidamente a mudanças e gerar valor para o produto. A elaboração do briefing e do business case é iterativa e incremental: designers, desenvolvedores e demais stakeholders atuam juntos para entender o escopo, identificar as necessidades e funcionalidades a implementar. O produto é desenvolvido a partir do aprendizado coletivo, de diversos tipos de testes e de controle de qualidade desde as etapas iniciais do projeto.

Como as pesquisas iniciais são fortemente orientadas a resultados, a equipe pode optar por fazer protótipos de papel em vez de questionários formais, para testar a recepção de ideias, conceitos e abordagens relacionadas ao produto, bem como a efetividade das soluções de risco mais alto. Por isto, desde o início cria-se modelos que evoluem ao longo do projeto. Os requisitos (resumidos) e as primeiras soluções de design são produzidos quase ao mesmo tempo.

O desenvolvimento em ciclos (sprints) evolutivos permite a prevenção de riscos e a absorção de mudanças ao longo da realização, para reduzir os custos globais e aperfeiçoar a inventividade das soluções. Os resultados de cada ciclo se mantêm afinados com os objetivos, ou os objetivos são alterados de modo consistente a partir dos resultados parciais dos testes e pesquisas.

Ao considerar o uso de métodos ágeis em um projeto de produto digital é importante, junto às dimensões técnicas, avaliar como o ambiente organizacional do cliente vai dialogar com o da contratada (ou departamento da mesma organização). Como são os relacionamentos internos, como pode ser feita a ligação com/entre eles? Podem ser informais ou devem seguir rituais pré-definidos? Para o uso do Scrum, é necessário ritualizar o final e o início de cada ciclo com reuniões, isto será possível? É importante levar em conta que pessoas e iterações multidisciplinares são mais importantes que os processos e as ferramentas.

Métodos ágeis podem ser usados quando o valor do projeto para o usuário final está claro desde o início. O cliente participa ativamente do projeto para o aperfeiçoamento contínuo do produto e a documentação visual (na maioria das vezes papéis com adesivos presos na parede, em vez de relatórios formais) é normalmente aceita, especialmente quando os principais desenvolvedores trabalham no mesmo local. O produto funcional é mais importante que a documentação, as interações do usuário (com narrativas testáveis, ou user stories) são mais importantes que processos e ferramentas, a colaboração interna é mais importante que negociações.

Plataformas ou aplicativos online se beneficiam especialmente desse modelo em ambientes criativos e dinâmicos, que geram produtos em permanente aperfeiçoamento, como sites/aplicativos/plataformas de comércio e de mídias.

Ver o estudo do caso do portal Hurricane Preparedness and Response for Florida Public Libraries, criado em 2009, que divulga como bibliotecas públicas podem ajudar comunidades a lidar com furacões na Flórida, criado em 2009. Embora não tenha seguido um método declaradamente ágil, o desenvolvimento foi realizado através de versões aperfeiçoadas em ciclos ou iterações.

Este método não permite muita elaboração de estratégias e modelos iniciais, pois normalmente não se dedica muito tempo ao planejamento, a ideações ou a exploração de múltiplas opções. O dono do produto estabelece os objetivos, e no final o resultado das ideações iniciais pode mudar para atender novos objetivos comerciais ou funcionais.

Pode-se optar por um modelo misto, que combine o desenvolvimento em cascata (ver abaixo) para as primeiras etapas de concepção com os modelos ágeis aplicados para o desenvolvimento. De qualquer forma, o tempo de produção de documentação sobre o projeto não deve exceder o tempo de desenvolvimento do produto.

Extreme Programming (XP) – Variação dos métodos ágeis que estabelece que as mudanças podem ocorrer mesmo entre sprints, e as equipes podem mudar imediatamente o curso do trabalho planejado anteriormente.

Desenvolvimento (de software) Lean – Outra variação de método ágil, em que se procura adaptar o rigor da gestão à medida justa da complexidade do projeto. Limita a produção de documentos, a realização de reuniões, o número de etapas, os recursos envolvidos apenas ao estritamente necessário para a realização do projeto e a adição de valor ao produto. Promove a verificação contínua do produto como a mínima solução viável, baseando-se na máxima de que “o mínimo é suficiente para seguir adiante.” O produto de cada etapa é o mais próximo possível do resultado final, mesmo que em determinado momento não passe de um protótipo funcional. Sete princípios básicos do Lean: 1 – Eliminar desperdício; 2 –  Amplificar a aprendizagem; 3 – Decidir o mais tarde possível; 4 – Entregar (o produto) o mais rápido possível; 5 – Empoderar a equipe; 6 – Construir integridade (no produto); 7 –  Ver o todo (citações da Wikipédia).

 Baseado na colaboração e na relação multidisciplinar entre os integrantes da equipe de projeto, prioriza a experiência do cliente, ajustando os produtos de maneira contínua a um mercado consumidor em  transformação. Ideal para produtos que podem ser lançados antes de finalizados e aperfeiçoados gradualmente, como os de mídias sociais e participativas.

Lean Startup – Variação do desenvolvimento Lean criada por Eric Ries, não inclui os sete princípios. Conjunto de processos usados por empreendedores às vezes descrito como “pensamento enxuto” (lean thinking) que procura incrementar a frequência de contato com clientes para validar ou eliminar o mais cedo possível as suposições incorretas sobre um produto, evitando desperdícios. Combina métodos ágeis, motivação de clientela (Customer Development) e plataformas de software (de preferência de código aberto), e gira em torno do “produto minimamente viável” (minimum viable product, MVP) – estratégia de testes quantitativos e rápidos  do mercado de um produto ou de seus recursos pela criação de modelos rápidos para validar suposições, usando o retorno dos clientes reais para aperfeiçoá-los.

Com a máxima “desenvolva-meça-aprenda”, o retorno do cliente real é valorizado, porque este modelo pressupõe que existe uma relação entre a motivação do usuário e sua habilidade para lidar com uma tarefa que aponta para o inverso de usabilidade. Sim, quanto mais motivado o usuário se sente para realizar uma tarefa, mais facilmente a realiza. Nesse caso, se uma tarefa tiver usabilidade sofrível, mas o cliente tem uma excelente motivação, ainda assim a fará. Mas se não estiver tão motivado, a tarefa precisa ser muito mais fácil de fazer. Assim, o modelo lean startup evita avançar no desenvolvimento de produtos que mesmo com excelente usabilidade, são ignorados pelo mercado.

Desenvolvimento em cascata – As atividades são realizadas em ordem linear: depois do preparo dos requisitos, desenvolve-se os produtos de uma etapa, aprova-se os produtos, segue-se para a etapa seguinte.

Apesar do escopo definido e da pouca abertura a mudanças, os projetos desenvolvidos em cascata, como projetos em geral, são sujeitos a imprevistos e mudanças. Qualquer alteração pode acarretar em aumento de custos e adiamento de prazos, pois as fases estão interligadas, o início de uma depende do encerramento da anterior. Para evitar o excesso de rigidez, é importante que a equipe se mantenha aberta a novas demandas, ocorrências e invenções durante a realização.

Dependendo do escopo e da expectativa de duração, os resultados de cada etapa são acompanhados de documentação mais ou menos detalhada, que não só registra as ações realizadas como justifica os resultados obtidos.

O método em cascata é adaptável a projetos de produtos digitais de curta duração, com requisitos precisos e sem dependência de serviços de terceiros, como hot sites de produtos e eventos, bem como sites de pequenas empresas ou pequenas publicações. Também pode ser indicado para grandes projetos realizados com escopo estável, em organizações com relações funcionais formais e hierarquizadas, que demandam a formalização de processos e resultados detalhadamente documentados.

Desenvolvimento rápido de aplicação (Rapid application development, RAD) – Modelo de desenvolvimento de software interativo e incremental que enfatiza um ciclo de desenvolvimento curto, entre 60 e 90 dias. Inclui a modelagem do negócio, do processo, dos dados, da aplicação, a realização de testes e as modificações dos testes.

Em circunstâncias em que os requisitos e o escopo estão bem definidos desde o início este método permite a obtenção de resultados testáveis rapidamente. Pode ser arriscado se o escopo não estiver bem definido, pois uma revisão em etapas avançadas compromete toda a realização.

Projetos de hot sites com aplicativos participativos, como blogs e comunidades, que precisam ser lançados com prazos muitos curtos podem se beneficiar deste modelo.

Múltiplas estimativas (Multiple Estimating Method) – realizado a partir das estimativas de custos e prazos obtidos com base em uma WBS. As atividades estimadas começam pelas de mais baixo nível e de curto prazo e vão aos poucos em direção às de mais alto nível e de maior complexidade.

Requer a opinião de pessoas experientes em projetos desta natureza, para estabelecer parâmetros críticos à verificação da acertividade das estimativas, bem como à verificação de dados estatísticos da área de atividade e do mercado, para seu acompanhamento comparativo.

Funcionam bem em ambientes funcionais complexos em que os processos de decisão passam por diferentes instâncias de aprovação e comprovação. A opinião dos experts funciona muitas vezes como fator decisório, na medida em que conflitos de interesses internos podem dificultar os processos de aprovação dos produtos das diferentes etapas.

Control Gate Reviews – Conduz revisões de qualidade dos produtos depois de cada etapa principal e define as lições aprendidas, atualiza os custos do projeto, o cronograma e as linhas-mestras do escopo, para a realização das etapas restantes. Também o plano de negócios é reexaminado a cada etapa, de modo a verificar se o investimento ainda é viável. Combina elementos de desenvolvimento incremental ao desenvolvimento em cascata.

Pode ser usada em situações em que a organização interessada em uma solução web ainda não sabe a efetividade da solução e procura colocá-la à prova de modo exaustivo durante o desenvolvimento, para evitar os riscos de um lançamento equivocado.

Desenvolvimento Orientado por Hipóteses – Permite o teste de um problema antes de se começar a trabalhar na solução. Formula-se uma proposição prévia, ou uma hipótese, para explicar um fenômeno. A partir daí, a hipótese é testada de modo controlado. Caso o resultado esperado seja obtido, é confirmada a teoria inicial, podendo servir de base para novas proposições. Caso não seja confirmada, a hipótese inicial é abandonada e novas alternativas são buscadas.

Os principais benefícios dessa abordagem são as evidências mensuráveis e o aprendizado contínuo. O esperado realmente aconteceu? Se não, que inputs podem direcionar os próximos passos? Ou seja, investiga-se um fenômeno, adquire-se novos conhecimentos, são feitas correções, que são integradas aos  conhecimentos prévios.

Em última instância, o desenvolvimento de um produto ou serviço é um processo de teste de uma hipótese de um comportamento em um ambiente ou mercado em foco, para avaliação de modelos de negócio, de como o consumidor irá usar o produto ou de como os códigos se comportam num determinado ambiente.

Desenvolvimento caótico – Pode parecer estranho ou mesmo contraditório, um projeto de gestão que adote o caos como modelo. Mas há situações em que o modelo se aplica, especialmente em ambientes acadêmicos e experimentais. A equipe e os gestores enfraquecem os controles de processos e interações para pesquisar estudar técnicas, desenvolver ideias, fazer experiências, criar protótipos examinar os relacionamentos do produto em diversos contextos, selecionando as soluções mais simples e elegantes.

A solução que emerge desta abordagem pode ser inovadora e criativa, apesar de arriscada. No final das contas, pode ser a que melhor se adapta ao contexto específico de realização de projetos web de um modo geral. Bastante produtiva quando a equipe interna e o cliente têm perfil criativo e relações horizontais consolidadas por relacionamentos pessoais de confiança.

A lista acima é simplificada, há muitas outras opções de metodologias adotáveis para projeto de produtos digitais. A compreensão de cada uma ajuda a verificar o que permite fazer e como pode ser mais ou menos adequada a cada caso. Ajuda também a identificar as características de cada projeto, o contexto e a seleção das técnicas e as adaptações possíveis das metodologias.

É preciso considerar que projetos de produtos digitais incluem processos de criação sujeitos a condicionantes funcionais, editoriais, técnicos, comerciais. Isto os diferencia estruturalmente de projetos de engenharia, de sistemas, ou mesmo de aplicativos funcionais. E nem sempre a reação do usuário pode ser prevista em todas suas nuances, na medida em que está sujeita a impressões, gostos, sensações, relacionamentos, respostas. O imponderável e a subjetividade estão presentes no projeto, na medida em que são também dimensões do produto.

A maioria das metodologias de gestão de projetos se baseia na fragmentação em diferentes ciclos, mais fáceis de gerenciar. No entanto, as soluções mais criativas e dinâmicas podem prescindir de um modelo formal e amplamente utilizado e acabar resultando em produtos flexíveis e legitimados gradualmente pelo público. O importante é adaptar a técnica adequadamente aos objetivos do produto, ao retorno que se dele se espera, ao ambiente de criação (pessoas envolvidas no projeto, metodologias já usadas pelo cliente, dependência de tecnologias, recursos) e ao ambiente mais amplo em que o produto vai funcionar.

Design thinking

Não pode ser considerado como uma metodologia de gestão de projetos, mas como um modo de abordagem que perpassa as metodologias de gestão, para a resolução de problemas, a gestão de informações, a análise de conhecimento e a criação de propostas e soluções, produtos ou não, em diversos contextos. Enfrentando os problemas a solucionar sob diversos pontos de vista, considera a capacidade para “combinar empatia, de modo a colocar as pessoas no centro do desenvolvimento do projeto; criatividade, para gerar soluções e razão para analisar e adaptar as soluções para o contexto”. Aplicado em equipes multidisciplinares, busca “mapear a cultura, os contextos, as experiências pessoais e os processos na vida dos indivíduos para ganhar uma visão mais completa e assim, identificar as barreiras e gerar alternativas para transpô-las”. Para isto, o Design Thinking propõe um ponto de vista empático, que permite colocar as pessoas (sejam equipes de criação, sejam clientes) no centro do desenvolvimento de cada projeto e gerar assim produtos mais desejáveis para elas, financeiramente interessantes e tecnicamente viáveis (citações da Wikipédia).

Segundo este modelo, é importante sair e conversar com os clientes, descrevê-los como personas, descrever seu dia, seus contextos de ação (cenários). O pensamento inovador surge a partir do entendimento do que é importante para o usuário. O que o usuário faz hoje para resolver esse problema e por que o faz assim? A alternativa proposta é melhor? O cliente compraria e usaria este produto? Quando o pensamento coletivo cria uma visão estável do problema e, a partir daí, proposições de valor claras, pode-se aplicar um modelo ágil como Lean para descrevê-las em user stories e testá-las com protótipos u modelos funcionais.

(Publicado em 16.2.2010. Atualizado em 16.11.2017)

 

Referências

É chegada a hora do desenvolvimento de software orientado por hipóteses, Barry O’Reilly (CIO, acesso em 16.1.2017)

Cost effective approaches to iteration in Agile UX (User Inserface Engeneering, acesso em 10.9.2014)

Bringing user centered design to the agile environment, Anthony Colfelt (Boxes and arrows, 31.1.2010, acesso em 19.3.2010)

Living on the edge, Kathleen Haas, PMP (Project@Work, acesso em 14.2.2010)

Resumo do PMBoK, José Ignácio Jaeger Neto, PMP (PDF, 83 páginas, acesso em 15.7.2009)

 

Ferramentas online para a gestão de projetos

  Asana permite que os usuários padronizem interfaces de acordo com preferências e padrões de produtividade, grátis para até 15 usuários  (acesso em 7.10.2015)

  Podio  rede social corporativa  com funções de gerenciamento de projeto  (acesso em 7.10.2015)

  Trello  ferramenta com versão gratuita, com listas de tarefas compartilhados em tempo real, adequado para métodos ágeis  (acesso em 7.10.2015)

  Jira ferramenta adequada para métodos ágeis  (acesso em 7.10.2015)

10 Free project management applications, de Laura Spencer (Freelance Folder, acesso em 19.3.2010)

Ace Project (gratuito para até 5 projetos e até 5 usuários, acesso em 14.2.2010)

Comind Work (ferramentas de projeto em grupo, como blog e wiki, gratuito no plano básico, acesso em 14.2.2010)

BaseCamp (acesso em 14.2.2010)

ActiveCollab (acesso em 14.2.2010)

Feng Office (acesso em 14.2.2010)

Central Desktop (acesso em 14.2.2010)