Realizar projetos de mídias digitais é altamente competitivo, dinâmico, e requer dos pofissionais envolvidos que compreendam essa complexidade contextual e a dos produtos, para selecionar a metodologia de gestão mais adequada ao contexto de projeto e ao uso do produto.

A seleção da metodologia de gestão leva em conta as situações contextuais, comerciais, técnicas de cada produto e também os contextos de desenvolvimento que se adaptam ao estilo de liderança dos gestores do projeto e dos usuários dos produtos. Entre 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, bem como a efetividade das soluções de risco mais alto. 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.

Uma agência, 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 vai dialogar com o do cliente. 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 as negociações.

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

► 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. Embora não tenha seguido um método declaradamente ágil, o desenvolvimento foi realizado através de versões aperfeiçoadas em ciclos/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 as ideações iniciais mudam 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 modo, o tempo de de documentação do projeto não deve exceder o 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 necessário para realizar o projeto e adicionar de valor ao produto. Promove a verificação contínua do produto como a mínima solução viável (“produto minimamente viável”, minimum viable product, MVP), 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 num 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, 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 também gira em torno do “produto minimamente viável” – estratégia de testes quantitativos e rápidos do mercado de um produto ou de seus recursos pela criação de modelos 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 o 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. Neste caso, se uma tarefa tiver usabilidade sofrível, mas o cliente tem uma muita 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 todos os 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 registra as ações realizadas e 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 obter 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 assertividade 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 de 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 as etapas restantes. Também o plano de negócios é reexaminado a cada etapa, para verificar se o investimento ainda é viável. Combina elementos de desenvolvimento incremental ao desenvolvimento em cascata.

Pode ser usado em situações em que a organização interessada em uma solução online 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. Testa-se a hipótese de modo controlado. Caso se obtenha o resultado esperado, confirma-se a teoria inicial, podendo servir de base para novas proposições. Caso não seja confirmada, a hipótese inicial é abandonada e busca-se novas alternativas.

Os principais benefícios desta abordagem são as evidências mensuráveis e o aprendizado contínuo. O esperado realmente aconteceu? Se não, que inputs direcionam 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 é o de teste de uma hipótese de um comportamento em um ambiente ou mercado em foco, para avaliação de modelo de negócio, de como o consumidor irá usar o produto ou de como os códigos se comportam num determinado contexto.

■ 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 de produtos digitais de 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, 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 pelo público. O importante é adaptar a técnica 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 do produto.

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 (equipes de criação, clientes) no centro do desenvolvimento de cada projeto e gerar 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, conhecer 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 esse 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 ou modelos funcionais.

(Publicado em 16.2.2010. Atualizado em 16.11.2018)

 

Ver também

→ É 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)

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)

→ 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)