Existem vários tipos de projetos, alguns mais simples e outros tão complexos que definitivamente não podem ir adiante sem um mínimo de ajuda. De fato, não adianta contar com as ferramentas se você não sabe por onde começar um projeto e o planejamento de tudo isso, não é mesmo?

Neste artigo vamos tratar sobre como começar um projeto. Quais devem ser os recursos, os prazos e as pessoas envolvidas? Como organizar, da concepção ao monitoramento, de forma a ter segurança para tomar decisões e flexibilidade para gerenciar o projeto e entregar valor para o cliente? Sem esses dados em mãos pode ser melhor até ficar parado do que caminhar para ter que refazer depois.

É claro que cada gerente de projetos tem sua própria metodologia de trabalho, mas isso não nos impede de dar os passos básicos para que você possa começar um projeto da forma mais tranquila e eficaz possível. Certamente, ao longo do tempo, você refinará essa checklist e encontrará sua própria maneira de fazer as coisas acontecerem. Por enquanto, melhor ter uma noção do essencial. Então anote aí:

Comece por uma boa pesquisa

Quando a ideia de um projeto surge, tem-se uma visão segmentada do valor que ele efetivamente pode gerar, de quais são seus riscos e se ele é realmente viável ou não, certo? Para desenvolver uma compreensão completa de cada caso, o segredo está na pesquisa. Vá em busca de informações sobre o mercado, os concorrentes e as inovações do momento. Identifique quais são as oportunidades de negócio que esse projeto pode trazer, que barreiras que você vai enfrentar e como superá-las, munindo-se com o máximo de informações possível. Não esqueça de registrar corretamente esses dados.
Outra dica importante é pesquisar internamente. Que projetos parecidos já foram executados? E desse cliente, esse será o 1º? Se não, quais foram os outros e o que foi alcançado?

Corra atrás de conhecimento

Tendo pesquisado bastante para começar seu projeto, chegou a hora de trocar conhecimento com outras pessoas. Boas formas de aprofundar essa pesquisa é buscar a opinião de profissionais que já tenham desenvolvido o mesmo tipo de projeto, visitar fóruns e comunidades on-line, acompanhar grandes nomes da área por meio de livros, artigos e cases de sucesso, por exemplo. Crie grupos focais para debater o assunto e se cerque de profissionais que possam oferecer o suporte necessário em momentos de dúvida. Vá em busca de experiências semelhantes e aprenda o máximo possível com elas!

Use a experiência a seu favor

Se você já desenvolveu projetos no mesmo segmento de mercado ou participou de equipes que trabalharam em iniciativas semelhantes, use essa sua experiência para definir por onde começar. Em suas empreitadas anteriores, o que deu certo e o que deu errado? Como você e sua equipe agiram em relação ao planejamento? Você tem algum registro das lições aprendidas? Revisite-as, afinal, você pode não se lembrar de todos os detalhes!

Defina seus objetivos com clareza

No que consiste seu projeto? Por que ele é importante para a empresa? Que tipo de resultados ele deve trazer com sua conclusão? Ter objetivos bem definidos é fundamental para o desenvolvimento de um projeto de sucesso! Quando você sabe onde está e onde pretende chegar, pode traçar o percurso com mais facilidade, avaliando os riscos e as oportunidades, a fim de estruturar o plano do projeto com a segurança e a flexibilidade necessárias.

Para não deixar nenhum fio solto, crie uma declaração de escopo, ou seja, um documento que defina exatamente o que será desenvolvido, detalhando todos os recursos necessários, assim como as premissas e restrições do projeto.

Reúna o time certo

Com a ideia geral bem estruturada e os objetivos traçados, vá em busca do time certo para desenvolver o projeto. Nessa hora, deixe as afinidades pessoais de lado e avalie quem está melhor preparado para levar os trabalhos adiante. Determine quais são as competências necessárias, quem trabalha melhor em equipe e que tipo de tarefa cada pessoa vai desempenhar para colocar a pessoa certa na função adequada.

Lembre-se: mais importante do que ter um time de gênios é ter um time de profissionais alocados onde se sentem confortáveis para colocarem suas competências em prática. Vale ressaltar que o time certo também precisa do líder certo para funcionar em sinergia! Portanto, promova um ambiente de interação contínua e nunca deixe de motivar as pessoas que trabalham com você!

Distribua e comunique papéis

Pessoas certas nos lugares certos também presumem distribuição adequada de papéis e responsabilidades, viu? Afinal de contas, se seu time não sabe o que é esperado dele, é bem possível que algo saia dos trilhos. Sendo assim, antes de efetivamente começar um projeto, defina o que será responsabilidade de cada um, registrando esse compromisso com o estabelecimento de metas individuais e mantendo todos cientes das inter-relações de atividades, para que um não impacte negativamente no trabalho do outro.

Converse com todos os stakeholders

Começar um projeto sem ter uma boa conversa com todos os stakeholders nunca é uma boa ideia. Pense bem: você precisa saber quais são as expectativas de cada público e como cada um impacta, positiva ou negativamente, no projeto. Só assim poderá gerenciá-los com qualidade. Então alinhe os objetivos e os resultados do projeto com cada stakeholder, ouvindo-os com atenção e procure envolvê-los na iniciativa.

Nessa etapa, destaque os benefícios que o projeto trará e como esses públicos serão impactados, além de criar um fluxo de comunicação que os mantenha informados sobre o andamento dos trabalhos. Só não descuide desse relacionamento, pois é ele que garantirá o sucesso para todos!

Estabeleça um fluxo de comunicação

O que informar, quando e para quem? Essas são algumas das perguntas que você deve se fazer ao estabelecer um fluxo comunicacional para o projeto. Além disso, defina os canais a serem utilizados na comunicação, visando controlar com eficiência todo o fluxo de informações com os stakeholders. Compartilhe um protocolo de comunicação com a equipe e deixe todos cientes a respeito de como os dados serão tratados ao longo do projeto. Níveis de acesso às informações também devem ser estabelecidos, a fim de garantir o sigilo de dados estratégicos.

Crie a carta do projeto como guia

Por fim, crie o project charter — ou a carta do projeto —, documento que será a diretriz para todas as suas ações a partir do início dos trabalhos. Nele constarão o escopo, o cronograma, os recursos, o orçamento, as premissas e as restrições. Aproveite o know-how da sua equipe para construir um guia realmente confiável, compartilhando as informações e deixando que os demais deem sugestões. É claro que não se trata de um documento inflexível, mas procure mantê-lo atualizado, sempre registrando o porquê de cada mudança, para não perder de vista seu objetivo final.

Outra forma de desenvolver uma carta do projeto é usando um software de gerenciamento de projeto, que além de oferecer controle sobre os itens já citados deste documento, oferece também gerenciamento de pessoal, relatórios diversos e muito mais!

E você, por acaso já possui uma forma para começar um projeto? Que pontos desse seu método batem com a nossa checklist? Deixe seu comentário e compartilhe suas dicas conosco! Aproveite para conferir este post com 12 passos para planejar um projeto e este outro post sobre qual metodologia adotar: ágil ou tradicional.

Se você é um profissional da área de gestão de projetos, possivelmente trabalha sob os princípios do Manifesto Ágil, ou, pelo menos, já ouviu falar sobre esse documento.

Mas, será que você realmente sabe o que é o Manifesto Ágil e a partir de qual demanda essa proposta surgiu? E, ainda: já se perguntou como cada um dos princípios afetam o desenvolvimento do projeto de forma prática?

Se respondeu não para algum dos pontos acima, o artigo de hoje é para você! Que tal conhecer um pouco mais sobre o importante documento que é o Manifesto Ágil para aplicá-lo de forma mais consciente? Continue a leitura e confira!

A história do surgimento do Manifesto Ágil

Em meados dos anos 2000, um grupo de pessoas influentes da comunidade do Extreme Programming se reuniu para discutir diversos pontos que envolvem o processo de desenvolvimento de software com XP (Extreme Programming).

Nessa reunião, foram levantadas questões como os efeitos da burocratização do processo e o excesso de formalização com documentações presentes no Extreme Programming.

Naturalmente, então, inseriu-se no debate os benefícios de novos métodos que eram contrários a essa formalização exagerada, os chamados métodos leves (Lightweight Methods).

O resultado foi que os presentes perceberam que havia um espaço comum entre os dois métodos, que deveria ser observado mais de perto.

Assim, um dos integrantes do grupo — Robert Cecil Martin, conhecido como Tio Bob — resolveu convidar os interessados para uma segunda reunião e, assim, se aproximar desse espaço comum.

Ocorrida no estado americano de Utah, nos dias 11 a 13 de fevereiro de 2001, essa segunda reunião se tornou um marco para os profissionais da área de gestão de projetos, e contou com a presença de 17 pessoas muito influentes nesse setor.

No decorrer do debate, foi verificado um consenso sobre os fatores importantes no desenvolvimento de software e, assim, todos decidiram que valia a pena registrar tais questões em um documento.

Aqui, aliás, vale lembrar que essa não era a intenção inicial dos presentes, mas se tornou inevitável quando eles perceberam que estavam lidando com algo grande, e que deveria ser tratado como tal.

Assim, ali mesmo, eles elaboraram um documento que se tornou um divisor de águas para o setor:

o Manifesto para o Desenvolvimento Ágil de Software, mais conhecido como Manifesto Ágil ou Agile.

Esse documento, que reúne um conjunto de valores e princípios, teve como principal objetivo nortear as ações das equipes ágeis, mantendo-as focadas no que realmente agrega valor tanto para o projeto quanto para o cliente.

Baseado em 12 princípios, ele se tornou uma espécie de guia que orienta as ações, as escolhas de métodos e ferramentas dos times ágeis de projetos, maximizando os resultados. Foi uma verdadeira revolução!

Para ter uma real dimensão do impacto e do peso do Manifesto, basta pensar que além de Robert Cecil Martin, nomes como Jeff Sutherland e Ken Schwaber — fundadores do Scrum — estavam entre os dezessete signatários.

Também estavam presentes nessa reunião: Jim Highsmith, Kent Beck, Arie van Bennekum, Alistair Cockburn, Mike Beedle, Martin Fowler, James Grenning, Andrew Hunt, Ron Jeffries, Jon Kern, Robert C. Martin, Steve Mellor, Ward Cunningham, Brian Marick, Ken Schwaber, Jeff Sutherland e Dave Thomas.

Os quatro valores do Manifesto Ágil

Um ponto que merece destaque sobre o Manifesto para o Desenvolvimento Ágil de software é que ele se firmou sobre quatro valores, e doze princípios.

O objetivo desses fundamentos era mostrar para os profissionais do setor quais eram os fatores valorizados por essas pessoas presentes na reunião, ajudando outros profissionais a fazer o mesmo.

Assim, definiram como mais importante a se valorizar:

— Indivíduos e a interação entre eles, mais que processos e ferramentas;
— Software em funcionamento, mais que documentação abrangente;
— Colaboração com o cliente, mais que negociação de contratos;
— Responder a mudanças, mais que

Na prática, esses valores informam que os profissionais devem saber da importância dos itens à direita, mas que os itens à esquerda possuem maior peso para o processo. Ou seja, eles creditam mais valor ao produto e ao processo.

Os doze princípios do Manifesto Ágil

Além dos quatro valores instituídos, firmou-se ainda um conjunto de abordagens de desenvolvimento de softwares que pode ser apresentado por meio de 12 princípios. A saber:

PRINCÍPIO 1: valor

“A maior prioridade está em satisfazer o cliente por meio da entrega adiantada e contínua de software de valor.”

O principal objetivo das equipes ágeis não é entregar um produto final, segundo determinados requisitos, mas entregar valor para o cliente. Ou seja, entregar uma solução que traga os melhores resultados.

Na prática, isso implica na priorização da felicidade do cliente, de sua satisfação. E essa nova forma de ver representou uma quebra de paradigma para o setor, pois passou a ser mais importante desenvolver um crescimento orgânico do software.

Trocando em miúdos, o desenvolvimento passou a ser incremental, a partir das necessidades observadas do dia a dia, não mais apenas do briefing inicial. Esse princípio lembra a máxima do marketing: entender para atender.

O próximo princípio trará mais detalhes sobre sua prática.

PRINCÍPIO 2: flexibilidade

Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas, aceitando alterações de requisitos mesmo no fim do desenvolvimento.
Perceba como os princípios estão interligados. Quando o primeiro princípio abre espaço para a satisfação do cliente, ele já abarca o segundo, que é ter um projeto flexível e passível de alterações.

Em um mercado cada vez mais competitivo e complexo, é preciso desenvolver projetos de maneira flexível, para que possam sofrer alterações de acordo com o contexto em que a empresa está inserida e com suas necessidades, que podem mudar durante o desenvolvimento.

Isso é, para satisfazer plenamente ao cliente, é necessário que o gestor do projeto tenha em mente que, se for necessário, ele terá que fazer alterações, inclusões, exclusões etc.

Mas essa flexibilidade somente será aplicável se o projeto tiver uma frequência de entrega, como veremos a seguir.

PRINCÍPIO 3: frequência

“Entregar o software em funcionamento com frequência, seja na escala de semanas ou meses, dando preferência a períodos mais curtos.”

Novamente, há o entrecruzamento, para que o projeto seja flexível e tenha como prioridade a satisfação do cliente — na prática, ele deverá ser entregue por partes. Cada etapa estará sujeita a validação e, por consequência, o produto final terá maior valor para o cliente.

Lembra quando falamos de um processo de desenvolvimento incremental? É isso! A cada sprint concluída, o time do projeto deve entregar uma funcionalidade ao cliente, com total capacidade para ser utilizada desde o primeiro momento.

Isso ajuda desde a percepção de valor até a testes e integrações com outros componentes do projeto.

Princípio 4: união

“Tanto pessoas relacionadas a negócios como desenvolvedores devem trabalhar em conjunto, diariamente, durante todo o curso do projeto”.

O envolvimento da gestão da empresa é fundamental para que os projetos sejam desenvolvidos de acordo com as expectativas do cliente. Essa colaboração é o que permite personalizar a solução e validá-la a cada sprint concluída.

Não é à toa que um dos papéis mais importante de um time ágil é do Product Owner, profissional responsável por ser um representante do cliente durante todo o processo de desenvolvimento. Quer saber mais sobre as atribuições deste personagem? Aproveite este artigo e conheça como se divide um time de Scrum.

Princípio 5: motivação

“Para construir projetos ao redor de indivíduos motivados, é preciso dar a eles o ambiente e o suporte necessários, confiando que farão seu trabalho”.

É fundamental que a equipe do projeto esteja motivada a desempenhar seu papel e tenha um ambiente adequado para desenvolver suas atividades, com suporte tanto na orientação das atividades quanto na adequação das metodologias ágeis.

Inclusive, se você leu este artigo sobre a divisão do time de Scrum, conseguiu identificar a figura do Scrum Master nesse princípio, certo?

Ainda, é importante que os gestores do projeto tenham em mente que as ações para que esse princípio seja posto em prática são de duas frentes, igualmente importantes: manter a equipe motivada e subsidiar a equipe com o suporte necessário.

Princípio 6: comunicação

“O método mais eficiente de transmitir informações tanto externas como internas para um time de desenvolvimento é por meio de uma conversa cara a cara.”

Se você voltar às demandas que iniciaram o surgimento do manifesto, perceberá que a burocratização era um desses pontos. Entretanto, é preciso ter em mente que o manifesto não quis excluir todas as formas de comunicação, mas sim otimizá-las.

Isso é, identificou-se que era preciso cortar o exagero de documentação que engessava e atrasava o processo.

Enfim, reuniões de planejamento de Sprint são fundamentais, sim, e fazem parte dos princípios do manifesto. Afinal, o registro de atividades não é tão eficaz quanto uma reunião da equipe do projeto para alinhar objetivos, trocar conhecimentos e planejar as próximas ações.

Princípio 7: funcionalidade

“Um software funcional é a medida primária de progresso”

A evolução de um projeto desenvolvido a partir de métodos ágeis é estimado pela entrega de um software funcional e não pela conclusão de atividades.

Agora, resgate os primeiros princípios apresentados neste artigo: viu como a funcionalidade é o resultado para a união dos três primeiros, valor, flexibilidade e frequência?

Assim, no ato do fazer — no caso desenvolver softwares — os princípios se imbricam. E isso ocorre porque o manifesto é fruto da observação do ato de fazer e da escolha das suas melhores maneiras.

Princípio 8: sustentabilidade

“Processos ágeis promovem um ambiente sustentável, com patrocinadores, desenvolvedores e usuários sendo capazes de manter passos constantes.”

Deve-se construir o ambiente ideal para o desenvolvimento de projetos, com planejamento por iterações e envolvimento de todos os afetados pelo trabalho. Esse processo deve ser contínuo, e todos devem estar disponíveis para acompanhá-lo e dar o devido suporte.

O mais importante nesse tópico é se atentar para construir algo com os recursos atuais, sem esgotá-los e multiplicando-os para usos futuros.

Princípio 9: revisão

“A contínua atenção à excelência técnica e ao bom design aumenta a agilidade.”

A revisão constante dos requisitos técnicos como também do design permitem a entrega de uma solução realmente alinhada aos objetivos de negócio do cliente, dispensando grandes mudanças no momento da entrega final.

Princípio 10: simplicidade

“Simplicidade é a arte de maximizar a quantidade de trabalho que não precisou ser feito”.

Menos é mais! Como os métodos ágeis dispensam boa parte de registros e outros documentos que comprometem o tempo da equipe, o trabalho se torna mais simples de ser executado. Sendo, portanto, concluído em menos tempo. Assim se garante o time to market do cliente.

Princípio 11: organização

“As melhores arquiteturas, os requisitos e os designs emergem de times auto organizáveis.“

Times ágeis são compostos por profissionais com a capacidade de se organizarem por si mesmos. Ou seja, de dividirem as tarefas e responsabilidades entre eles, sem que um gerente de projetos tenha que interferir.

Princípio 12: autoavaliação

“Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.”

Na prática, esse princípio consiste na revisão do trabalho realizada que, ao final de cada sprint, permite que a própria equipe avalie sua performance e descubra formas mais interessantes de trabalhar e agilizar todo o processo.

A continuidade do Manifesto Ágil

Por fim, o manifesto representou um grito de liberdade de práticas que atravancam o processo.

No momento, era sabido que, embora dificilmente a essência (valores e princípios) mudasse, era necessário ter uma organização que prezasse por seu contínuo aperfeiçoamento e que o representasse.

Assim, com esse propósito, no final do mesmo ano (2001), surgiu a Agile Alliance. A organização sem fins lucrativos se tornou responsável por compartilhar esse conhecimento e promover debates sobre os diversos métodos ágeis existentes no mundo.

A discussão, bem como a própria organização, são fundamentais, pois o Agile é como um guarda-chuva, que abarca vários métodos que se assentam sobre seus princípios e valores.

Assim, essa contínua discussão ajuda a criar um norte para que os desenvolvedores de softwares saibam escolher os melhores métodos ou ferramentas.

E você, já desenvolve essas práticas na sua empresa? Como vem percebendo os resultados? Se gostou desse artigo, aproveite para compartilhá-lo em suas redes sociais!

Como uma das partes interessadas mais importantes de qualquer iniciativa é o cliente, é fundamental mantê-lo informado e envolvido em tudo o que está acontecendo, não concorda? É impensável pensar, por exemplo, que a gestão de um projeto pode ser bem-sucedida sem que se tenha atendido as expectativas do contratante e feito uma boa manutenção da gestão de clientes! Então, nada mais essencial que estabelecer relações estreitas com esse decisivo stakeholder.

Por essas e outras, a organização, o gerente e a equipe devem mover montanhas para captar quais são as impressões, as necessidades e os objetivos dos clientes. Assim será possível exercer uma boa gestão e, consequentemente, obter sucesso com o projeto. Está achando tudo muito complicado? Não se preocupe, porque não é tão difícil quanto parece! Atentando-se para as dicas que selecionamos para o post de hoje, fazer a gestão de clientes de forma correta, se tornará uma tarefa bem mais simples do que espera. Confira!

Consistência na postura

O gerente de projetos precisa agir de modo firme, sabendo exercer sua liderança tanto em relação à equipe como no que diz respeito ao cliente. Assim ele se torna uma referência como sendo o direcionador dos esforços para a produção de tudo aquilo que deve ser entregue. Esse comportamento, além de contribuir para a finalização gradual do escopo, permite que a gestão de projetos conquiste e trabalhe em conjunto com a gestão de clientes.

A propósito, as periódicas reuniões normalmente realizadas são ótimas oportunidades para o gestor exercitar essa habilidade, mostrando seu comprometimento com os resultados e evidenciando sua preocupação junto a esse importante stakeholder.

Outro ponto importante é que uma postura consistente impede a ocorrência do engessamento dos processos, fenômeno que ocorre quando a equipe adota diferentes metodologias ou normas em diversos pontos do projeto. Esse contexto torna as atividades mais burocráticas do que deveriam ser e atrapalham, principalmente, a fluidez das interações com fornecedores externos ou com os próprios clientes do projeto.

Diferenciação das partes

Os clientes obviamente têm um interesse expressivo nos resultados da iniciativa. E vale lembrar que isso inclui não só a empresa contratante que efetivamente fará uso do produto final, mas também o patrocinador ou qualquer outro executivo que disponibilize recursos para um projeto interno.

Com isso em mente, a equipe deve saber diferenciar bem o que abrangem os termos partes interessadas e clientes, de forma a ter consciência de que esses últimos são indivíduos com necessidades dos serviços da equipe, bem como da entrega no final do projeto. Com base nessa premissa, a organização passa a ter condições de melhor atender e priorizar as demandas.

Estabelecimento de valores

Mas não basta apenas saber diferenciar o cliente das demais partes interessadas, é necessário saber o que exatamente o cliente entende como importante. É necessário desenvolver a gestão de clientes. Isso automaticamente torna as ações dos gerentes de projeto mais conscientes. O entendimento dos critérios de valor é crucial, devendo ser definidos em conjunto com o cliente, de acordo com suas próprias percepções sobre o que é ou não importante.

Tendo a gestão de projetos focada em tais critérios de valor, os serviços podem ser alinhados às exigências e às necessidades dos clientes. Já que projetos são feitos por pessoas para outras pessoas, manter um diálogo aberto e claro entre os envolvidos é essencial para garantir que o resultado estará de acordo com as expectativas das partes.

Informações de status

É importante manter o cliente informado sobre o status do projeto, o andamento das atividades e os marcos alcançados. Acredite: relatórios simples já podem evitar muitas confusões e mal-entendidos. Ao mesmo tempo, uma notícia comunicada em tempo hábil pode viabilizar uma intervenção a solicitada pelo cliente.

Por meio de reports periódicos, o cliente tem a oportunidade de fornecer feedback sobre o cronograma e também, se for o caso, questioná-lo. Não importa qual seja a ferramenta utilizada para manter essa atualização, o que é preciso guardar é que clientes participativos e comprometidos são também vitais para o sucesso do projeto.

Necessidade de auditoria

Em determinado momento (principalmente no caso de projetos internos), o cliente poderá questionar sobre a aplicação do dinheiro. Onde exatamente cada parte do orçamento foi investida? Nessa hora, ter um projeto bem auditado faz toda a diferença. Muitos gestores consideram desnecessário exercer um controle minucioso de gastos, contudo, na medida em que o dinheiro vai sendo consumido, pode acabar surgindo um buraco negro se não houver um monitoramento de onde o capital foi aplicado. Nesse contexto, como explicar?

Como essa é uma situação que, com certeza, comprometeria muito a relação do gestor com o cliente, é necessário definir padrões sobre como o projeto será acompanhado, quais processos precisam ser estabelecidos e seguidos. Do contrário, dados importantes podem se perder, frustrando não só a credibilidade junto ao cliente como prejudicando a formação de índices comparativos para o uso em empreendimentos futuros.

Gestão de fornecedores

Assim como é necessário realizar uma boa gestão da equipe, o gerenciamento dos recursos externos também é importante. Por mais que seja comum contratar fornecedores, terceirizando alguns trabalhos, a gestão desses stakeholders não pode ser delegada. A principal vantagem de contratar um terceiro é a possibilidade de transferir a responsabilidade de entrega (desde que o contratado tenha capacidade para tal, é claro). Contudo, é fundamental que o gerente de projetos tenha movido esforços para deixar claro aquilo que é valor, ou seja, o que é realmente importante para o cliente final.

Esse é o aspecto mais importante ao contratar um parceiro para fornecimento: explicitar que existe um padrão de entrega que deve ser atingido tendo como foco as necessidades e expectativas do cliente. Para tanto, a gestão deve considerar a especificação de métricas de qualidade e, é claro, definir muito bem os prazos para os fornecedores.

Como você pôde perceber, maiores ganhos e melhores resultados podem ser alcançados quando se estabelece um adequado relacionamento com o cliente, ou seja, quando existe a gestão de clientes. É fundamental que haja diálogo e real compreensão daquilo que é requisito de sucesso para os participantes do projeto. E não só o gestor como também a equipe toda devem reconhecer os clientes não como geradores de aborrecimentos, mas sim como membros de uma relação de cooperação e parceria, frutífera para ambos os lados!

Agora nos conte aqui, como anda a relação gestão de clientes na sua empresa?

Independentemente do tipo da empresa (seja ela pública ou privada), seus recursos financeiros, humanos e materiais são limitados. Por isso, é essencial identificar e priorizar a gestão de projetos no terceiro setor, que proporcionarão maiores ganhos e que realmente estejam alinhados aos objetivos estratégicos da organização. Só assim é possível garantir o uso equilibrado de tais recursos.

Mas após essa ponderação começa outra fase fundamental: a gestão dos projetos selecionados, ou seja, gestão de projetos no terceiro setor. Os esforços passam a se concentrar, então, no atendimento às estimativas de custo, tempo, escopo e qualidade, além da necessária atenção às expectativas e necessidades dos stakeholders. E é aí que entram as técnicas e melhores práticas em gerenciamento de projetos, parte imprescindível para o sucesso também das organizações do Terceiro Setor.

Mas qual é a melhor maneira de aplicar a gestão de projetos no Terceiro Setor? Como superar os desafios? É claro que o conjunto de conhecimentos em gerenciamento de projetos é fundamental, mas existem algumas características específicas que devem ser consideradas. Veja a seguir:

Construção de metodologia

Um dos maiores obstáculos para as organizações do setor terciário está na estruturação de processos e na determinação de uma metodologia para o gerenciamento dos projetos. Surge, nesse âmbito, um ponto em comum entre as organizações do Terceiro Setor e as demais empresas: não existe uma receita pronta. A verdade é que cada organização tem seus valores, sua cultura, sua história e suas peculiaridades (organizacionais, hierárquicas e processuais). Com o passar do tempo, elas tendem a consolidar alguns modelos que carecem apenas de poucas adaptações.

Mas é possível dizer que, infelizmente, esse processo ainda está em seu estágio inicial no Terceiro Setor. Exatamente por isso, uma corrente de estudiosos, pesquisadores, autores e instituições voltaram sua atenção para a gestão de projetos no Terceiro Setor nos últimos anos. E por mais que, como resultado, tenham surgido algumas propostas interessantes de gerenciamento de projetos para o segmento, ainda há um longo caminho a percorrer pela frente. Na prática, a entidade não deve somente buscar uma metodologia baseada em modelos que atendam às suas especificidades. É importante chamar a responsabilidade para si, construindo um modelo próprio em consonância com as melhores práticas já conhecidas.

Indicadores de desempenho

Outro desafio bastante evidente e ainda mais complexo que a definição de metodologias e processos é a determinação de indicadores referentes ao impacto social dos projetos e das ações realizadas pelo Terceiro Setor. Por se tratar de projetos cujos impactos estão relacionados, basicamente, à melhoria da qualidade de vida das pessoas, nem sempre é possível quantificar objetivamente o progresso alcançado. E isso desencadeia imprecisão e prejuízos na comparação do previsto versus o realizado, pois não é possível identificar claramente em que medida o objetivo foi alcançado. Por isso, é importante que existam iniciativas de identificação, definição e elaboração de indicadores apropriados para a aferição do impacto social dos projetos.

Retorno dos projetos

É muito comum que as organizações do Terceiro Setor desprezem o retorno financeiro dos projetos, afinal, crê-se que, pela falta de fins lucrativos, não faz sentido se ater a esse quesito. Entretanto, justamente pela carência desses recursos é que o retorno financeiro se mostra como uma variável importante nesses projetos. É de suma importância, portanto, que os recursos da instituição e também de seus mantenedores e parceiros sejam investidos de forma eficiente, a fim de proporcionar o maior impacto social possível. É crucial, inclusive, desenvolver maneira como se mede o impacto social dos projetos e, se viável, mensurar o resultado financeiro correspondente.

Gerenciamento dos interessados

Em projetos do Terceiro Setor, normalmente existe um alto grau de influência de partes interessadas, afinal, os projetos tendem a impactar um grande público e lidar com diferentes instituições (tanto públicas como privadas). Sendo o benefício para a sociedade e a vida das pessoas o principal objetivo do escopo de tais projetos, o gerenciamento transparente e eficiente das partes interessadas se transforma em fator decisivo para o sucesso. É fundamental, portanto, estabelecer um alto grau de colaboração com as partes interessadas.
Os gerentes de projetos e a alta direção das organizações do Terceiro Setor devem estabelecer um relacionamento estreito com os stakeholders, tornado possível abstrair suas impressões no que se refere aos avanços, efeitos, benefícios, problemas e impactos da iniciativa. Como qualquer sinal de insatisfação pode ter consequências negativas na condução dos trabalhos ou na credibilidade da entidade, a adequada gestão das partes interessadas é uma área de conhecimento muito importante.

Gestão de riscos

Em decorrência do maior envolvimento das partes interessadas, o gerenciamento de riscos em projetos do Terceiro Setor passa a ter uma importância ainda mais expressiva. Afinal, é normal que os resultados estejam atrelados a aspectos culturais, socioeconômicos e educacionais da comunidade. Logo, os riscos se potencializam. E o mesmo se aplica às oportunidades.

Convém lembrar que os riscos não se resumem a eventos e situações negativas. Os eventos e as situações de impacto positivo são oportunidades que devem ser, sempre que possível, identificadas, mensuradas e aproveitadas. Sendo assim, o gerente de projeto deve garantir que os riscos não afetem negativamente a iniciativa e que as oportunidades sejam plenamente aproveitadas e revertidas em prol do sucesso final.

Gestão de projeto para o Terceiro Setor no mundo

Dada a importância das iniciativas de contribuição social sem fins lucrativos, a Organização das Nações Unidas (ONU), por meio dos Escritórios de Serviços de Projetos das Nações Unidas (UNOPS), tem participação ativa no Terceiro Setor. Esse braço apoia os projetos relacionados à paz e à estabilidade pós-conflitos, à recuperação das comunidades acometidas por catástrofes naturais, ao desenvolvimento de recursos humanos para a melhoria das economias locais e para suplantar os desafios ambientais e de sustentabilidade relacionados às alterações climáticas.

O objetivo da instituição é implementar e aperfeiçoar a prática de gestão de projetos dentro dos esforços humanitários de construção da paz e desenvolvimento de infraestrutura em mais de 80 países (como Iraque, Afeganistão, Haiti e Sri Lanka). E vale a pena dizer que essa entidade conta com a expertise de um representante brasileiro: o mineiro Ricardo Vargas, escolhido para assumir o cargo de Diretor do Grupo de Práticas de Projetos do Escritório de Serviços de Projetos das Nações Unidas.

Como é possível constatar, não há uma necessidade de se investir altas quantias para contornar as dificuldades da gestão de projetos no Terceiro Setor. O que se deve fazer é, na verdade, adotar uma cultura de gestão que prime pela eficiência e por boas práticas em entidades de cunho social, culminando no aumento da eficiência e no crescimento desse importante segmento da sociedade, que transforma a vida das pessoas e que constrói um mundo melhor para todos.

Quer saber o segredo para um planejamento bem-sucedido? Simples: acompanhamento de projetos! Afinal de contas, monitorando todas as variáveis possíveis, tudo tende a caminhar de acordo com o previsto. Com o controle adequado, será possível fazer melhor uso dos recursos, maximizar os resultados e garantir que os objetivos do projeto sejam atingidos com o mínimo de surpresas indesejadas pelo percurso.

Tudo bem que projetos de menor complexidade são mais fáceis de monitorar e controlar, mas conforme crescem as exigências do cliente, você precisa automaticamente aumentar seu grau de controle. Afinal, o objetivo é sempre atingir os maiores níveis de sucesso. Mas como fazer um controle de projetos de forma eficiente? Pois descubra agora mesmo!

Crie uma rotina de acompanhamento

Para o acompanhamento de projetos, na etapa de planejamento você faz previsões, determina prazos, custos e recursos (dentre tantos outros itens que devem ser monitorados) para que o escopo do projeto seja atingido conforme o acordado com o cliente. A partir desses dados, você cria uma checklist de itens a serem verificados diária, semanal, quinzenal ou mensalmente, dependendo da complexidade do seu projeto.

Essa checklist deve ser de conhecimento de todos e envolver todas as áreas do projeto, a fim de monitorar as métricas de desempenho bem como o previsto versus o efetivamente realizado. Com essa tática, caso haja qualquer desvio, é possível agir rapidamente para corrigir o caminho e manter as atividades conforme o planejado.

Defina uma forma de controle

Ao identificar os objetivos e as metas do projeto, você atribui a eles métricas ou indicadores de performance. São os chamados KPIs. Esses KPIs servem para que você acompanhe a evolução das atividades ao longo do tempo e saiba exatamente quanto falta para atingir os objetivos e as metas propostos para o projeto.

Já falamos bastante sobre indicadores de performance aqui no blog, mas é válido relembrar que eles devem ser mensuráveis, realistas e fáceis de compreender. Dessa forma, toda a sua equipe saberá exatamente como está o acompanhamento de projetos e o que deve ser feito para finalizá-lo com eficiência e qualidade.

Colete e analise dados periodicamente

Uma boa forma de coletar e analisar dados no gerenciamento de projetos é com o auxílio de uma ferramenta de Business Intelligence (BI). Essa ferramenta tem a capacidade de processar uma quantidade gigantesca de dados e informações em questão de segundos, detectando padrões e tendências que dificilmente seriam identificados de outra forma.
No âmbito do gerenciamento de projetos, o BI pode ser aplicado na identificação de falhas do processo. Se toda vez que uma atividade se repete acontece um determinado problema, o BI será capaz de fazer essa ligação e informar a você e à sua equipe a causa da falha persistente, mesmo que ela não esteja tão evidente quanto você gostaria.

Socialize a informação

Indicadores de performance, bem como os relatórios analíticos extraídos do BI devem ser comunicados a todos os membros do time para que cheguem a um consenso sobre o que deve ser feito a fim de corrigir eventuais falhas e desvios.

Além de manter o registro de todas as informações em um local de fácil acesso (como um software de gestão de projetos), você também deve promover reuniões presenciais e abrir canais de comunicação que facilitem a troca de ideias e experiências entre todos os envolvidos. Para isso, pode optar por chats, aplicativos de troca de mensagens, grupos de discussão, entre outros.

Mantenha o foco no progresso

No acompanhamento de projetos, não adianta ficar constantemente discutindo o passado. Se atrasou um dia no seu cronograma, olhe para a frente e veja como é possível compensar esse atraso para que o cliente não seja prejudicado com essa falha de gestão.

Um Gráfico de Gantt ou ainda um dashboard Kanban podem ajudar a manter seu cronograma em dia e o status do projeto sempre atualizado para todos os envolvidos. O Gráfico de Gantt funciona como a sua linha do tempo, com todas as tarefas distribuídas, enquanto o quadro Kanban serve para acompanhar a produtividade da sua equipe em cada tarefa.
E é fato que o controle minucioso dessas duas ferramentas ajudará a equipe a agir proativamente para evitar problemas maiores, como a não entrega de uma funcionalidade no prazo estipulado ou mesmo uma entrega de qualidade duvidosa.

Faça os devidos ajustes

A verdade é que todo projeto é passível de falhas e imprevistos, cabendo a você manter a tranquilidade e orientar sua equipe para fazer as correções necessárias o mais brevemente possível. Nesse sentido, o acompanhamento dos KPIs e também dos dados coletados e analisados por meio do BI é fundamental.

Essas duas ferramentas de controle devem estar perfeitamente alinhadas e integradas a seu software de gerenciamento de projetos para que você tenha uma visão completa e sistêmica de tudo o que acontece no decorrer do projeto. Caso contrário, poderá enfrentar dificuldades em fazer a leitura do contexto global em que está inserido.

Tenha sempre os resultados em mente

Controlar projetos é olhar para onde você está e saber aonde quer chegar, identificando melhores formas de encurtar esse caminho. Quando você mantém o foco nos resultados que deve gerar para o cliente, fica muito mais fácil tomar decisões e seguir adiante sem se prender a erros passados.

Ensine também sua equipe a manter o foco nos resultados. Dessa forma, a criatividade e o pensamento crítico estarão sempre voltados para encontrar maneiras mais ágeis e efetivas de entregar aquilo que o cliente espera e precisa. Com tudo isso, aumenta-se o valor agregado de cada projeto.

Cada vez que você deixa de controlar um projeto, perde oportunidades, desperdiça recursos e compromete o tempo da sua equipe com atividades que poderiam ser eliminadas, aumentando a eficiência de cada entrega. Portanto, no momento do planejamento, defina como seu projeto será monitorado e controlado, quais são os indicadores de sucesso e como eles devem ser medidos.

O acompanhamento de projetos começa no kick off, ou seja, no pontapé inicial. Desse momento em diante, nada de perder de vista seus indicadores de performance nem os dados gerados com a execução de cada fase. E por falar em indicadores de performance, que tal compreender de uma vez por todas o que são esses tais de KPIs em gerenciamento de projetos?

Em épocas passadas, muitas das empresas que investiam recursos em Business Intelligence (BI) acabavam não logrando êxito em suas operações. As constantes queixas dos usuários sobre a má qualidade das informações e a dificuldade em lidar com os sistemas e as ferramentas de BI eram prova mais que suficiente disso. Mas a verdade é que esses problemas eram acarretados por detalhes nos projetos de implementação. Na prática, quando o BI é bem implantado, torna-se uma ferramenta de valor inestimável no gerenciamento de projetos.

Vale dizer que o BI não se baseia apenas na instalação de aplicações tecnológicas para automatizar processos, mas sim em uma forma de captar dados consolidados, capazes de oferecer ao gestor condições de colocar em prática uma série de análises e projeções antes de tomar qualquer decisão. Com tamanho amparo tecnológico, o BI consegue otimizar os trabalhos de todo o time enquanto acompanha e sinaliza sobre possíveis problemas. Não parece ideal? Então acompanhe os tópicos seguintes e veja como melhorar a produtividade da equipe de implementação!

ESTABELECIMENTO DE REQUISITOS

Dada sua importância, e partindo do pressuposto que foram bem determinados, o BI deve começar pela definição dos KPIs (ou indicadores-chave de desempenho), que são o cerne de qualquer software de Business Intelligence. Afinal, esses indicadores acabam sendo traduzidos nas informações de negócios mais relevantes para empresa.

Nesse cenário, toda a equipe (composta majoritariamente por colaboradores do setor de TI, mas também por outros departamentos especializados) deve determinar quais dados devem ser tratados pelas aplicações de BI, quando é necessário que estejam disponíveis e em que formato. Dessa maneira, a eficiência dos trabalhos tende a ser muito maior.
Definição dos usuários

Deve-se dedicar especial atenção à determinação dos usuários do BI. Dessa forma é possível evitar conflito de papéis, problemas referentes ao sigilo de informação e ruídos na comunicação. A equipe do projeto deve, portanto, determinar quem serão os utilizadores da solução, que podem ser divididos, basicamente, em três grupos:

• Usuários gerais de relatórios;
• Produtores e analistas que estudam os dados;
• Gestores que estipulam os objetivos.

Com a correta organização dos usuários (quem são, quais informações devem receber e quais são suas respectivas responsabilidades), a produtividade do time como um todo é otimizada.

Envolvimento dos utilizadores

Ainda no que se refere aos usuários, a TI deve desenvolver um protótipo simples da solução. Dessa forma, pode-se fazer revisão a fim de garantir que os requisitos fundamentais sejam contemplados desde o início. No decorrer da implantação de um projeto de BI, os membros dos setores especializados devem sempre ser considerados (até porque, futuramente, serão eles os que trabalharão com as aplicações). Por isso, dependendo do resultado do teste do protótipo, serão esses os colaboradores que determinarão se o projeto atende ou não às necessidades, se deve ou não haver mudança.

Apoio da gestão

Assim como em qualquer tipo de projeto, a equipe deve poder contar com o apoio da alta gestão. Assim, os objetivos corporativos de curto e longo prazos têm grandes probabilidades de serem alcançados. Isso quer dizer que a alta cupula da empresa não deve atribuir o sucesso ou o fracasso da iniciativa somente ao gestor, afinal, ela mesma tem grande influência nesses resultados e na performance de todo o time.

Confiabilidade dos dados

A confiabilidade dos dados é essencial para o sucesso de um projeto de Business Intelligence. Para tanto, a equipe deve determinar como as informações serão disponibilizadas e como os dados devem ser acessados. Para o caso de informações atualizadas em tempo real, por exemplo, o acesso direto é a melhor opção. Se o fornecimento de dados brutos não for suficiente, o tratamento deverá ser aprimorado por meio de software apropriado para seu gerenciamento.

Padronização dos processos

Logo na iniciação de um novo projeto, é necessário estudar se as ferramentas anteriormente utilizadas devem ou não continuar para o projeto vigente. Caso a organização não conte com uma padronização de BI, é fundamental que dê início a esse processo a fim de garantir dinamismo e produtividade, evitando retrabalhos.

Escolha do software

Antes que a empresa efetivamente escolha a solução que pretende utilizar, é importante rascunhar quais são suas necessidades e o que espera de um software de BI. Munida dessas informações e, é claro, com o apoio da equipe de projeto, deve decidir qual a ferramenta mais adequada. Com isso, a probabilidade de a organização escolher a melhor solução para o negócio aumenta significativamente. A propósito, a Project Builder conta com BI em sua solução de gerenciamento de projetos, viu?

Limitação do tempo

Quando se está implementando um novo projeto de BI, os esforços dos departamentos especializados devem estar concentrados em dar passos claros e muito bem definidos. Um bom parâmetro é determinar que os primeiros módulos estejam executáveis e operacionais depois de dois ou três meses, no máximo.

Ferramenta de comunicação

Não se pode ignorar o fato de que a aplicação de uso do BI deve ser explorada em todo o seu potencial de ferramenta de comunicação. Afinal, a solução possibilita gerenciar a tramitação de dados de diferente formas e até ajustar o modo de apresentação de resultados de acordo com as partes interessadas. Logo, dentro da estratégia de comunicação, o uso do Business Intelligence é mais uma alternativa para os gestores na apresentação de relatórios de resultados e no acompanhamento do andamento do projeto de forma dinâmica e transparente.

Finalmente, é interessante dizer que a implementação de BI é um processo. Por se tratar de um projeto interno, os requisitos da organização podem mudar constantemente, refletindo diretamente na aplicação de BI. Isso significa que todas as ferramentas de Business Intelligence precisam ser desenvolvidas e aprimoradas continuamente. Do contrário, seria impossível cumprir todas as demandas de cada departamento.

Como você viu, dentre as mais variadas funções que o BI pode realizar dentro de uma empresa, destacam-se o controle, o monitoramento e a comunicação, instrumentos extremamente relevantes e carentes de soluções tecnológicas eficientes. Logo, com a devida atenção aos trabalhos da equipe de implantação, os resultados só demonstram o quão versáteis são as aplicações de BI no mundo corporativo e seus impactos significativos no aumento da produtividade.

Deseja saber mais sobre Business Intelligence? Então não deixe de conferir nosso guia para dobrar sua inteligência em negócios e saber tudo sobre o tema!

A reunião para planejar o sprint é um momento fundamental para o projeto, pois ela vai definir quais tarefas vão entrar neste determinado sprint e a prioridade delas. Engana-se quem acredita que a metodologia ágil elimina o planejamento e parte para a execução de maneira cega. Tudo é acompanhado, mas de forma otimizada, pois não temos tempo a perder!

Neste post, vamos falar em como funciona as reuniões para como planejar o Sprint para que estas não sejam mais longas do que devem (a metodologia é ágil, lembre-se disso) e todos saiam satisfeitos e com clareza do que devem produzir a seguir.

PRÉ-PLANEJAMENTO

Uma dica que serve para toda a reunião é uma boa preparação prévia. O Product Owner deve estar afinado com as necessidades do projeto e a equipe (assim como o Scrum Master) devem ter a real noção d capacidade de produção do time. Uma vez alinhados é hora de partir para a reunião de planejamento dos sprints propriamente dito.

A reunião

A reunião para planejar o sprint tem na verdade duas partes. Na 1ª, é definido as demandas para a equipe e a presença do Product Owner é imprescindível pois ele irá descrever um conjunto de estórias desejadas do produto e prioridade entre elas para a equipe. O objetivo é fornecer as informações suficientes para o time traçar as tarefas necessárias para a criação da funcionalidade desejada.

Vale lembrar que só equipe é capaz de definir o que ela é capaz de realizar no próximo Sprint. O Product Owner não deve fazer nenhuma pressão para incluir algum item e é função do Scrum Master, o mentor e facilitador do time, zelar para que a equipe compreenda o que deve ser fazer e que somente aceite tarefas e prazos que consiga cumprir.

Já na 2ª parte da reunião, o foco é como a equipe irá realizar as funcionalidades desejadas, como as tarefas serão executadas, aqui a presença do Product Owner é opcional, mas ele deve estar disponível para tirar qualquer dúvida da equipe. Nessa etapa é definido o sprint backlog, a lista de estórias e tarefas a serem concluídas durante o sprint.

Uma dica importante é dedicar 1h em cada uma das partes para cada semana planejada, assim, se o seu sprint é duas semanas, sua reunião vai durar aproximadamente 4h (2h da 1ª parte e mais 2h da 2ª parte).

Resumindo: ao final da reunião de planejamento do sprint, teremos:

• A meta do sprint.
• Data e local definidos para a reunião diária.
• A relação dos membros do time envolvidos e seu nível de comprometimento.
• O sprint backlog (lista de estórias que serão trabalhadas neste determinado sprint).
• Data de apresentação do sprint.

E se o planejamento do Sprint falhar?

O carácter incremental e iterativo da metodologia ágil diminui as falhas de planejamento, pois alia contato constante entre os envolvidos e planejamento com tempo delimitado e meta clara como resultado. Porém, diversos fatores podem aparecer para alterar o planejamento feito para uma determinada sprint ou até mesmo cancelá-la!

Má avaliação da prioridade dos itens do backlog, da real capacidade da equipe em atender certa demanda e até mesmo o surgimento de uma funcionalidade pelo cliente que não estava prevista. O gerente de projetos precisa estar atento e ser capaz de realizar as mudanças necessárias para não prejudicar os prazos e nem permitir que surjam atrito entre equipe e Product Owner.

A forma mais fácil de fazer as correções necessárias é buscar as estórias impactadas pelo problema e alterá-las, com isso buscar aproveitar o máximo do que já havia sido acordado durante a reunião de planejamento de sprint. Outra alternativa é substituir estórias que ainda não haviam sido iniciadas por aquelas criadas a partir das novas necessidades do projeto. O objetivo aqui é evitar atraso no prazo anteriormente estipulado.

Agora, caso a meta da sprint já não faça sentido com as novas premissas do projeto ou o que iria começar a desenvolvido simplesmente já não faz mais parte do escopo do projeto, não resta outra coisa a se fazer a não ser cancelar a sprint. Mas não se preocupe, pois essa é uma medida extrema e raramente necessária.

E aí, preparado para realizar sua reunião de planejamento de sprint? Conte como você e sua equipe organiza seus sprints!

Um burnup chart (ou gráfico de burnup) fornece informações sobre o status do projeto como um todo e não apenas do sprint, como é o caso do gráfico de burndown. É uma ferramenta que exibe claramente em que ponto o time está no que se refere às entregas e onde ele precisa chegar quando se trata de demandas.

Já podemos adiantar que esse gráfico é constituído de dois eixos: o eixo horizontal apresenta o fator tempo e o eixo vertical vem com o montante de trabalho. Nessa lógica, as unidades de trabalho podem ser representadas por pontos, medidas de esforço ou até horas, conforme o que é praticado no dia a dia pela equipe. Quer conhecer mais sobre esse recurso? Então acompanhe agora mesmo nosso post:

Conceituação básica

O burnup chart consiste em faixas que representam o progresso em direção à finalização do projeto. De forma mais simples, existem duas linhas no gráfico:
• Uma linha de trabalho total (a linha do escopo do projeto);
• Uma linha de trabalho concluído.

Assim, esse gráfico mostra claramente tanto o escopo do trabalho como também o projeto concluído, com a iniciativa sendo finalizada na medida em que as linhas se aproximam. No eixo vertical consta a quantidade de trabalho, medida em unidades personalizadas, de acordo com a realidade do projeto. Já o eixo horizontal representa o tempo, normalmente medido em dias. Com o passar do dias, é possível observar a quantidade de trabalho sendo finalizado e o volume do que ainda se pretende concluir. Quando as duas projeções se encontram, o projeto estará completo! É ou não é uma forma de acompanhamento extremamente útil?

Monitoramento e controle

Uma parte fundamental da gestão do projeto é a verificação regular do progresso. Para tanto, o burnup chart é uma ferramenta extremamente importante. Certos problemas (tais como o aumento do escopo ou um desvio qualquer) podem ser facilmente identificados por meio do gráfico de burnup. Dessa maneira, dada a rápida identificação de uma possível falha, ações corretivas podem ser tomadas em tempo hábil e não quando já é tarde demais. Com isso, a competência da gestão só cresce. Promover uma comunicação assertiva com o cliente por meio do compartilhamento do burnup chart também pode ajudar a conquistar sua confiança tanto no que se refere aos trabalhos de gestão como no que tange o progresso do projeto como um todo.

Uma das grandes vantagens de um burnup chart é a inclusão da linha de escopo. O gráfico controla, de forma clara, todas as demandas adicionadas ou removidas, além de também permitir a visualização de uma data de conclusão mais realista para os trabalhos por meio de uma linha de tendência. Ao fazer o acompanhamento dessa linha, o gerente de projetos identifica facilmente onde os esforços estão concentrados e os impactos na data de conclusão. Ao distinguir se o trabalho adicionado é de origem do cliente ou da equipe, torna-se possível planejar uma resposta mais assertiva.

Mas atenção: por mais que um burnup chart típico tenha apenas duas linhas, outras linhas também podem ser incluídas, correspondendo, por exemplo, ao desempenho ideal para servir de padrão de comparação. Com isso, é possível identificar, de forma mais ilustrativa, se o projeto está adiantado ou atrasado. Ao notar se a linha de desempenho real está acima ou abaixo da linha ideal e observando a distância existente entre essas linhas é possível ter uma ideia do quão à frente (ou atrás) a iniciativa está na programação.

Razões para uso

Vale ressaltar que um dos maiores objetivos de qualquer gráfico é a comunicação. E um burnup chart o faz direta e claramente, informando sobre o trabalho em curso. Funciona, assim, como uma ferramenta extremamente eficaz para o gerenciamento das partes interessadas. Os pedidos de funcionalidades adicionais realizados por parte do cliente, por exemplo, desde que bem gerenciados e visíveis aos olhos de todos, podem ser melhor compreendidos, estudados e planejados para garantir que não afetem negativamente o prazo final da iniciativa. Esse acompanhamento e a devida publicidade garantem que o trabalho progredirá da melhor forma.

Enquanto o gráfico de burndown não exibe os avanços que vêm sendo conquistados pela equipe, impedindo inclusive que o cliente acompanhe o desempenho na medida em que adiciona trabalho ao projeto, um gráfico de burnup permite que os clientes avaliem rapidamente se tudo está em conformidade com o planejado ou se é necessário acionar algum alerta.

Pode ser que seja necessário dar uma explicação extra sobre a interpretação do burnup chart para as pessoas que não estão muito familiarizadas com esse tipo de visualização e informação. No entanto, devido aos inúmeros benefícios percebidos com a utilização do gráfico, dedicar um certo tempo para esse esclarecimento é plenamente aceitável, compensando todo os esforços de elucidação que se imponham.

Criação do burnup chart

É possível criar um gráfico de burnup de muitas formas, desde apostando na elaboração manual (com caneta e papel) até por meio de um programa de suporte (como com o Excel), ou mesmo adotando softwares de gerenciamento de projetos que contenham esse gráfico em suas ferramentas. Para desenvolver um burnup chart, o ideal é integrar a fonte de dados ao gráfico, automatizando sua atualização. Entretanto, não custa nada lembrar que não se deve reinventar a roda. Então não hesite em lançar mão dos diversos modelos já disponíveis para adaptação em vez de comprometer um tempo desnecessário para a criação de um gráfico de burnup totalmente do zero.

Como você viu, os gráficos de burnup exibem o que já foi feito até o momento em contraste com o montante total do projeto. São ferramentas imprescindíveis de acompanhamento no gerenciamento ágil e apresentam, de forma rápida e simples, o progresso a todas as pessoas envolvidas na iniciativa (desde o Product Owner, passando pelo Scrum Master até chegar ao time de desenvolvimento).

Pronto para potencializar a compreensão de informações em relação ao andamento dos projetos da sua empresa? Então invista na elaboração (ou adaptação) de um burnup chart e se prepare para ótimas surpresas nos resultados! E por falarmos em resultados, que tal aproveitar para entender como métodos ágeis afetam os resultados de uma empresa?

Sigla para Minimum Viable Product (ou produto minimamente viável), é importante saber o que é MVP e que ele pode ser considerado um dos primeiros degraus que o empreendedor deve subir antes de iniciar qualquer que seja seu negócio. Ele funciona como uma espécie de plataforma de observação e coleta de dados dos clientes, a fim de construir situações práticas de negócio que permitam aprender, de forma rápida, o preço a ser praticado, os diferenciais buscados pelo público e as funcionalidades a serem desenvolvidas, tudo com o objetivo de oferecer ao mercado uma solução inovadora. 

É como se fosse um protótipo para a elaboração de um produto certeiro, que realmente tenha utilidade para quem o adquirir. Mas não é só isso! Passado algum tempo de inserção do MVP, ainda será possível se antecipar à concorrência, acredite? Pois acompanhe os tópicos seguintes e entenda melhor o que é MVP e como ele pode ser decisivo para o sucesso do seu negócio!

 
A realidade que não mente

Não é segredo para ninguém que um número expressivo de empresas fecham em seu primeiro ano de atividade. E a verdade é que uma grande parcela da culpa por esses fracassos precoces se dá pela falta de informações sobre o setor (tais como o número de clientes e seus hábitos de consumo), assim como pela negligência na identificação das necessidades do mercado. Assim fica mesmo complicado acertar a mão, não concorda?

Além de ser usado para atestar o atendimento do produto e de seus recursos às demandas do mercado, o MVP também serve para avaliar as necessidades dos usuários. Logo, tende a diminuir as chances de o negócio figurar no lado sombrio das estatísticas de falência. Afinal, com hipóteses testadas, é menos difícil errar o alvo.

O experimento pode estar focado no produto em si ou em outras variáveis que possibilitem a validação da proposta. O MVP ajuda a isolar claramente o problema que o produto ou o serviço se propõe a sanar, sendo por isso extremamente útil para validar ideias, que podem ser testadas e otimizadas repetidamente. Assim, os empreendedores que sofrem com dificuldades para obter uma clientela inicial poderão dormir despreocupados, já que, colocando o MVP em prática, o lançamento do produto já virá com uma carteira de clientes basicamente formada!

Como você pôde ver, a implementação do MVP consiste em processo bem simples, que se origina de conceitos já idealizados pelo empreendedor e tem a característica de ser ágil. Por essas e outras, é perfeito para startups em momentos de incerteza ou para empresas que carecem de economia tanto de tempo como de recursos financeiros. Mas engana-se, quem acredita que adotar MVP é exclusivo desse tipo de empresa, organizações maduras têm muito a se beneficiar com essa prática.

O MVP na forma de projeto

Caso a empresa ainda não tenha definido um protótipo ou, mesmo que já o tenha feito, quer transformar o processo em algo ainda mais eficiente, é interessante adotar um modelo de negócios baseado no Business Model Canvas, que consiste em 9 blocos que estabelecem os componentes básicos do negócio:

• Segmentação de clientes;
• Propostas de valor;
• Canais ou meios;
• Interação com o cliente;
• Origem de receitas;
• Recursos-chave;
• Tarefas-chave;
• Parceiros-chave;
• Composição de custos.

No caso da elaboração do zero, ou seja, quando não há nada parecido para que se possa comparar, realmente é mais difícil definir um MVP. Nessa situação, a melhor estratégia é realizar testes rápidos para se aprender com os erros e os acertos. Se o empreendedor ainda não tiver esmiuçado a fundo o nicho no qual pretende investir, o ideal é procurar por referências e mais conhecimento antes de iniciar o MVP, colocando suas concepções em prática só mais tarde.

A medição do MVP

É necessário estabelecer métricas para estudar o feedback tanto de clientes em potencial como daqueles que já fazem uso do serviço. Assim é possível aprender o que é necessário para aprimorar o produto ou eliminar um problema que venha a inviabilizá-lo no futuro. A ideia é de que os resultados das validações sejam rápidos e fáceis de analisar.

Que tal alguns exemplos? Para testar o conceito de compras coletivas, o site Groupon iniciou suas operações com um blog de ofertas que enviava os cupons em formato PDF, elaborados de forma manual. Outro caso similar é o da Zappos, que, para testar se a venda virtual de calçados realmente funcionava, abriu seu site na internet com apenas alguns modelos. Quando as pessoas adquiriam, a equipe se dirigia à loja física, comprava o par de sapatos e mandava para os compradores!

A seleção de recursos

Sabendo que muito se tem a ganhar em conhecimento sobre o mercado, as empresas devem investir no aprendizado de forma prática. Assim conseguem potencializar a percepção sobre o espaço para novidades. Nesse caso, uma dica importante é não deixar que o cliente note a fragilidade do MVP, por mais bruto que ele possa parecer (ou seja, o cliente deve ser atendido de forma impecável).

Caso seu negócio seja virtual, é importante se valer de ferramentas que otimizem o tráfego, investir em SEO, landing pages, Google AdWords, Facebook Ads ou mesmo na geração de conteúdo em blogs (como fizeram as startups citadas no tópico anterior). De maneira genérica, para produtos corporativos de alto valor agregado, o ideal é primeiramente testar por intermédio de apresentações e pesquisas com potenciais clientes.

Já para produtos voltados para pequenas e médias empresas ou mesmo para o consumidor final, validar a demanda via web também é uma boa estratégia. Dependendo do caso, a validação a partir da experimentação real do produto também pode ser interessante. Para modelos de negócio ligados à comercialização de publicidade, por sua vez, os MVPs devem se voltar para a elaboração do próprio produto em si.

O importante é compreender se o empreendimento está trilhando o melhor caminho ou se está indo na direção errada. Quando findar o ciclo de obtenção de ideias, determinação do escopo, aferição de dados, aprendizado, obtenção e análise de feedbacks, é necessário voltar a atenção para não se deixar envolver totalmente pelas opiniões dos usuários. Isso porque, muitas vezes, nem mesmo os clientes têm clareza sobre o que querem. Ao mesmo tempo, não é fácil ser autor de grandes inovações!

Na prática, o processo de implementação de um MVP gera uma bagagem ainda mais valiosa que a avaliação dos clientes em si. Por isso, o empreendedor deve ser criterioso e observador ao estabelecer sua estratégia, devendo fazê-la do modo mais simples possível para, então, poder desfrutar do sucesso de seu empreendimento.

Entendeu direitinho o que é o MVP e por que é necessário construir um antes de lançar seu produto no mercado? Ficou ainda com alguma dúvida sobre o assunto? Comente aqui e compartilhe suas impressões e seus questionamentos conosco!

Um product backlog eficiente é aquele bem priorizado, que não só torna o planejamento mais fácil, como também contempla os esforços no que se refere ao tempo de consumo e à descrição dos trabalhos internos que entregarão valor ao cliente. Com essas definições, torna-se possível gerenciar melhor as expectativas das partes interessadas e o empenho das equipes, especialmente quando o time está mobilizado na geração de valor agregado em cada uma de suas demandas.

O product backlog contém basicamente uma lista com todos os requisitos em questão, classificados ordenada e atreladamente a outras características que facilitam o planejamento e a devida priorização. Quer entender melhor? Então acompanhe os tópicos seguintes:

Criando a eficiência

Antes de mais nada, é importante dizer que o product backlog é o cerne do Scrum, basicamente onde tudo começa. Consiste em uma lista de requisitos (também conhecidos como estórias) que descrevem tudo aquilo que o cliente deseja com base em suas próprias palavras, sendo responsabilidade do Product Owner definir esse documento. Essas estórias (ou itens do backlog) devem incluir primordialmente os seguintes campos:

ID

Traduz-se como uma identificação exclusiva, um número sequencial, responsável por evitar que se perca o controle sobre as estórias quando os nomes sofrem algum tipo de alteração.

Nome

É importante atribuir um nome curto e descritivo. “Exibir o histórico das operações”, por exemplo. O segredo está em pensar em uma descrição suficientemente clara para que os desenvolvedores e o Product Owner compreendam, sem risco de mal-entendidos, do que se trata. Usar de 2 a 10 palavras é um bom parâmetro a ser usado.

Grau de importância

O grau de importância se refere à pontuação dessa estória para o Product Owner. A lógica é simples: quanto mais pontos, mais importante é a estória. É bom tentar evitar o uso da classificação prioridade, pois uma prioridade 1 é comumente interpretada como prioridade mais alta, por exemplo. E não soaria bem se, mais tarde, surgisse a necessidade de atribuir ainda mais importância a um outro determinado item de backlog. Nesse caso, qual pontuação de prioridade esse item deveria receber? Prioridade 0, -1? Para evitar essa confusão, recomenda-se a classificação por grau de importância.

Estimativa inicial

Trata-se das estimativas da equipe em relação ao tempo que será necessário para implementar uma determinada estória em comparação com as demais. A unidade utilizada é pontos por estória e normalmente diz respeito à relação ideal entre homem por dia.

Descrição

Esse campo se refere à descrição cuidadosa sobre como a estória será́ demonstrada na apresentação do sprint. É um passo a passo.

Notas

Nesse campo devem constar quaisquer outras informações, explicações, referências ou pequenas anotações que sejam interessantes deixar claro a respeito da estória.

Organizando o backlog

A organização do product backlog pode ser feita por meio do Excel ou por ferramentas de gerenciamento de projetos ágeis. Formalmente falando, o Product Owner é o responsável pelo documento. Mas os demais usuários não devem ficar de fora, afinal, um desenvolvedor pode sentir a necessidade de acessar o documento para esclarecer algo ou alterar uma estimativa, por exemplo.

Tendo em vista essa característica, o ideal é que o product backlog não seja arquivado em um repositório de controle de versões, mas sim compartilhado em um drive na rede ou em uma ferramenta online própria para a gestão de projetos. Essa é uma forma extremamente simples de viabilizar múltiplos acessos e edições simultâneas sem causar conflitos.

Mantendo a saúde

Uma vez que o product backlog foi elaborado, é importante monitorá-lo regularmente para garantir o cumprimento do cronograma. Para isso, o Product Owner precisa, antes de cada reunião de planejamento, consultar se existem atrasos, de forma a assegurar a priorização correta e fornecer os devidos feedbacks sobre as últimas estórias incorporadas. Caso o atraso se torne maior do que o tolerado, esse profissional deve agrupá-lo em itens de curto prazo e de longo prazo. Os itens de curto prazo devem ser plenamente finalizados assim que forem organizados. Já os itens de longo prazo podem contar com uma certa latência, intervalo que deverá ser utilizado para a determinar a priorização.

O product backlog serve de conexão entre o Product Owner e a equipe de desenvolvimento, detendo a liberdade necessária para retornar à lista de estórias sempre que preciso para priorizar o trabalho no backlog (seja devido ao feedback dos clientes, ao refinamento das estimativas ou mesmo a novas exigências). Contudo, uma vez que o trabalho está em andamento, deve haver o máximo de esforço para intervir o mínimo possível, de forma a não prejudicar a equipe de desenvolvimento em seu foco, seu fluxo e sua motivação.

Garantindo a agilidade

É bem comum que as partes interessadas desafiem as prioridades definidas. E isso é bom, uma vez que promover o debate em torno do que realmente é importante, equilibrando o que é considerado iminente entre todos os envolvidos. Esses diálogos fomentam uma cultura de priorização de grupo, assegurando que todos compartilhem da mesma mentalidade sobre o programa.

O product backlog também deve servir como um instrumento para o planejamento das iterações. Para tanto, todos os itens de escopo devem ser incluídos no backlog: estórias de usuários, erros, alterações de design, dúvidas técnicas, pedidos de clientes e assim por diante. Isso assegurará que os itens de trabalho estejam presentes na discussão global para cada iteração. Dessa forma, os membros da equipe podem, então, fazer as solicitações ao Product Owner antes de começar uma iteração, tendo o conhecimento completo de tudo o que deve ser feito.

A gestão do product backlog não deve se concentrar apenas na finalização das estórias, mas sim na própria forma de gerenciar! Esse é o ponto em questão. Assim, a organização deve estar constantemente analisando os incidentes, tudo para se antecipar a um eventual problema. Por isso se vê a importância de estudar as tendências, valer-se de métricas de acompanhamento e monitorar os status das iterações. Só assim a empresa terá condições de identificar a necessidade de intervenção e, mais do que isso, gozará de tempo suficiente para eliminar o ofensor.

E então, ficou ainda com alguma dúvida sobre o assunto? Quer saber mais? Pois aproveite para assinar nossa newsletter e ficar a par das novidades!