A life committed to learning.

Tag: Gestão de Projecto

Porque é que eu gosto das metodologias ágeis para desenvolvimento de Software?

Nesta história a equipa estava a trabalhar no lançamento de um produto para o mercado. O projecto já dura à um ano e é gerido com técnicas “tradicionais”* de desenvolvimento de software. Uma das iniciativas (ou sub-projecto, ou projecto no contexto de um programa) inclui um site,  um blog e um perfil no Facebook, no Twitter e no Youtube, onde se irá anunciar o grande lançamento do produto para o mercado.

Um mês antes do grande lançamento a equipa responsável pela comunicação pergunta ao desenvolvimento: “Quando é que o produto vai estar pronto? Precisamos de uma data para comunicar ao público o grande lançamento”.

A equipa de desenvolvimento respondeu qualquer coisa como: “Já está 85% feito.”

Com uma contas, o gestor de projecto prevê que dentro de um mês o produto estará pronto para o mercado. E foi com esse pressuposto que a equipa de comunicação anunciou a data do lançamento “imprevisível” do grande lançamento no site, no blog, no Facebook, no Twitter e no Youtube.

Mas será que aconteceu o pior?

No dia de lançamento (segundo as expectativas da equipa de comunicação), a equipa de desenvolvimento diz que não é possível lançar o produto hoje.

Infelizmente para a equipa, a data de lançamento calhou a uma Sexta-Feira, quando já todos andavam atacados com o stress pre-release. Depois do problema escalado, a direcção da empresa pede gentilmente que se esforcem ao máximo durante o fim de semana para lançar o produto na próxima Segunda-Feira. Até lhes ofereceu recompensas financeiras.

O produto é lançado na Segunda-Feira, mas apesar do incentivo financeiro,  a equipa perdeu muita motivação com este acontecimento. O overtime e sensação de “falha” é sempre um desmotivador e não há dinheiro que “mexa” nessa psicologia.

Agora, porque é que eu gosto das metodologias ágeis para desenvolvimento de software? Não vou aqui falar de tudo, é claro, mas apenas de um ponto que acho importante no contexto desta história tão comum.

Disciplina nas entregas (e tudo que o processo traz de borla)

  • A trabalhar com iterações que produzem Software “utilizável”  e com um conjunto de funcionalidades conhecidas, a equipa ganharia disciplina nas datas de entrega (Com uma gestão apropriada da equipa).
  • Se as iterações tivessem duração de 3 semanas e a equipa confiasse que necessitava de uma iteração para atingir um conjunto de funcionalidades, que somadas às produzidas nas iterações anteriores igualavam as funcionalidades mínimas para lançar o produto, então a equipa de comunicação poderia estar confiante ao anunciar a data do grande lançamento

Será este ponto importante para repensar algumas metodologias de desenvolvimento de Software? Ou assumimos a postura da  negação: “Ahh, podia ser pior se tivéssemos marcado um evento com a comunicação social e grandes investidores.”?  🙂

* Refiro-me aqui às técnicas que apenas são reconhecidas como boas práticas dentro da empresa um por um grupo restrito de empresas. 🙂

Continue Reading

Para os amantes do Ruby on Rails e não só

Este post é para os amantes de Ruby on Rails e não só. É também para os amantes do desenvolvimento de Software.

Para quem não conhece Ruby on Rails (RoR), RoR é uma framework para desenvolvimento ágil de aplicações Web. Utiliza a linguagem de programação Ruby. Uma framework equivalente, mas em Java, pode ser o  Tapestry 5, por exemplo, que também é uma framework para desenvolvimento ágil de aplicações Web, mas em linguagem Java.

RoR não é a única framework para desenvolvimento de aplicações Web com Ruby e uma das mais activas frameworks “rivais” ao RoR é a Merb.

A novidade aqui, pelo menos para mim, é o anúncio do merge entre Ruby on Rails e Merb no RoR 3.

Fica aqui um vídeo com a  novidade, dada pelo criador do RoR, que não é um anúncio, mas uma aula.

Para quem não liga nada a RoR, pode ver a partir do minuto 45, tem umas excelentes dicas para qualquer pessoa envolvida no desenvolvimento de software. 🙂

Quero aproveitar também para emendar um pequeno detalhe num dos meus últimos posts. No post ‘O poder do “E” e do ‘Mas’” quero alterar de Programador para Parceiro 🙂 . Vejam o vídeo a partir do minuto 58 para perceber porque é que quero mudar isso 🙂 . Ahh! E vejam também a resposta à primeira pergunta, a partir do minuto 59

Vale a pena ver mesmo quem não quiser saber nada de RoR, mas quiser saber alguma coisa sobre desenvolvimento de Software.

Continue Reading

O poder do “E” e do “Mas”

Acho que existe um poder psicológico no “E” e no “Mas”. O “E” tem um poder positivo, de criatividade e colaboração enquanto o “Mas”  tem um poder negativo e cria barreiras para a criatividade e colaboração.

Para o demonstrar, considerem as seguinte conversas:

Programador – “Vou conseguir terminar o módulo A a tempo”

Gestor de Projecto – “Sim, muito bem. Mas conseguirás fazer também a documentação a tempo?”

Pensem que isto vos está a acontecer e tentem perceber o roadblock que foi colocado apenas no vosso caminho?

Agora no mesmo cenário mas como uma atitude mais positiva:

Programador – “Vou conseguir terminar o módulo A a tempo”

Gestor de Projecto – “Sim, muito bem e agora temos de nos focar também em entregar a documentação a tempo? Do que precisamos?”

Pensem agora nesta última conversa. Qual delas será a mais construtiva, colaborativa, positiva e inteligente?

Continue Reading

O conhecimento é gratuito!

Será o conhecimento gratuito ou quase gratuito?  Não sei se existem muitas empresas em Portugal a utilizar mailing-lists efectivamente. Acho que as mailing-lists podem ser uma fonte de conhecimento gratuita.

Este poderá ser a história de muitas equipas em muitos projectos. É uma história de uma equipa de desenvolvimento de software que trabalhou para uma pequena empresa de fogões de sala. Eles ganharam um contrato de um projecto para integrar uma aplicação Web, desenvolvida em Java, com o Twitter. O projecto deveria estar pronto em 6 meses, sob pena de perderem 10 000€ por mês de atraso.

A empresa cliente vai experimentar utilizar o Twitter para aumentar as vendas e querem integrar o site com o Twitter. A cliente quer utilizar palavras chave associadas aos produtos para actualizar várias contas do Twitter. Cada actualização automática tem palavras chave de um produto e um link para a página do mesmo.

Depois de alguma pesquisa e análise, decidiram utilizar o Twitter4J, uma biblioteca de software em Java para abstracção da API Restful do Twitter.

Não tinham qualquer conhecimento na biblioteca Twitter4J. Inicialmente estimaram que demorariam cerca de 2 meses para ganhar o conhecimento e experiência necessária para fazer algo do género em seis meses.

Depois de um pequeno brainstorming chegaram a duas alternativas para colmatar a falta de experiência e eliminar, ou reduzir, qualquer risco de atraso.

Alternativa 1 – Contratar um consultor com conhecimento em Twitter4J para trabalhar no projecto durante dois meses que custaria ao projecto cerca de 15 000 euros.

Alternativa 2 – Assumir o atraso de 2 meses que custaria cerca de 20 000 euros.

Como ambas as alternativas custavam bastante dinheiro à equipa, eles decidiram seguir por outro caminho mais arriscado, mas que nunca poderia custar mais que a segunda alternativa. A alternativa seguida foi:

Alternativa 3 – Começar já a desenvolver qualquer coisa, e se tiveram alguma questão bloqueante utilizam as mailing-list do Twitter4J e da API Restful do Twitter.

Eles seguiram com a terceira alternativa, e qualquer dúvida eles colocavam questões nas mailing-lists, tendo não acesso a um consultor, mas a centenas de consultores que lhes respondiam quase imediatamente.

A equipa consegui terminar o projecto com um atraso de 1/2 mês, o que significou um prejuízo para equipa de cerca de 5 000, comparados com os 15 000 da primeira alternativa e os 15 000 da segunda.

Acham que  nesta história o conhecimento foi quase gratuito?

Disclaimer: Isto é mesmo só uma história 🙂

Continue Reading

O que faz uma boa equipa?

Num artigo do Financial Post de Setembro, pode ler-se o seguinte:

“An effective team has to be able to respond quickly[…] And for that, we need a forum for robust dialogue.

A formally constituted team comes from the desire to work collaboratively […] There is a shared commitment to goals that has the support of individual team members, and in turn supports them.

An effective team […] contrasts with a more common hierarchical approach to business goals, “the command-and-control approach.”

The effective team are […] The Magnificent Seven rather than The Good, The Bad and The Ugly.

To have and effective teams […]Businesses need to shift from individual bonuses to team-based bonuses, to flatten out their reporting structure.

What may not be a Team? […] A committee is a weak variant of a team […] A team […] is the opposite of a committee in that it has a unifying purpose and values to which all members ascribe, despite their position within the organization.

How to build a team? […] Peer mentoring is a team learning system that lets people teach each other […] Workshops have their place in leadership development, but most corporations don’t have a significant way to transfer that knowledge into skills.”

Peer Mentorig […] challenges people to take ownership of their careers. As long as no direct reporting is involved, it works magically.

How a effective team looks like?[…] include enough people, and a good cross-section of skills. We call it collective intelligence. The worst thing to do is try to figure out things by yourself.

Ainda no mesmo artigo são sugeridas oito características de uma boa equipa:

EIGHT TEAM MUST-HAVES

  1. Must have a meaningful purpose that all members care about.
  2. Can’t be too large. Some experts suggest capping at 20. Field cautions against there being too little work for all members.
  3. Needs a diverse set of skills appropriate to the goals.
  4. Needs to be physically together. Even having some team members on different floors can hurt the team.
  5. Succeeds or fails together. No stars or scapegoats.
  6. Shares leadership. Of course there is one leader, but he or she should be willing to step aside when another team member’s skills are required.
  7. Has strong shared norms and expectations of behaviour. These are soft skills that often need to be taught.
  8. Needs time. “You lose advantages if you hurry,” Prof. Field says. “Slow it down for the process to work.”

Artigo original:

http://www.financialpost.com/story.html?id=2258320

Continue Reading

Communities of Practice

Hoje tinha de escrever alguma coisa para o meu blog. Estou a tentar disciplinar-me na escrita e então decidi introduzir um tema que ando a tentar compreender melhor: Communities of Practice.

Uma Community of Practice é uma forma de criar e renovar conhecimento nas organizações. É por vezes uma solução na transformação de modelos de desenvolvimento de Software Waterffal para modelos mais ágeis e lean. Ao eliminar equipas especializadas (Testers, Architects, Developers, Designers) as pessoas podem perder as condições ideais para se especializarem em assuntos e áreas de interesse profissional.  Não acho que o facto de as equipas serem multidisciplinares e trabalharem em todos os aspectos do desenvolvimento do Software, seja justificação para acabar com o conhecimento que é criado através destas equipas.

Os Testers geralmente pesquisam e desenvolvem soluções que lhes permitem melhorar os testes de Software. Os Architects pesquisam e desenvolvem conceitos de Software que, sendo implementados, criam valor no produto. Os Developers pesquisam e desenvolvem soluções que  possam proporcionar um aumento de eficiência no seu trabalho. Acho que é importante que se continue a ter as condições para criar este tipo de conhecimento e uma das formas de o conseguir é através de Communites of Practice.

Ficam aqui alguns recursos sobre o assunto:

Vídeo:

Caterpillar- Collaboration Through Communities of Practice

Slides:

Communities of Practice: Conversations To Collaboration

Continue Reading
Continue Reading

Estudos de viabilidade, val, tir, payback e modelos de negócio

Tenho recebido algum tráfego, juntamente com alguns emails, à procura de saber mais sobre o assunto “Como seleccionar um Projecto“. Por isso decidi fazer uma visita a este assunto.

Você está a pensar em iniciar um novo projecto e necessita de um estudo de viabilidade económica. Depois de uma pesquisa na Internet encontrará os meus posts sobre o assunto:

Estes posts contêm informação sobre alguns assuntos a considerar durante o estudo e, além dos links úteis, disponibilizo também um modelo em Excel que pode ser adaptado às suas necessidades.

Download da Versão 4 do Modelo Económico

Mas é claro que toda esta informação se pode tornar confusa logo no primeiro post. É por isso que acho que o assunto dos modelos de negócio é pertinente para os estudos de viabilidade.

Entender o modelo de negócio não é só primeiro passo para um estudo de viabilidade, mas é também a base para o sucesso do negócio. Por isso tenha um modelo de negócio simples para nunca se esquecer dele. 🙂

Oscar Osterwalder utiliza uma ferramenta visual para este processo que chama “business model canvas”.

O “business model canvas” é composto por quatro pontos relacionados com o financiamento e operação do negócio:

  • Actividades Chave – Quais são as principais actividades do negócio?
  • Rede de parceiros – Apoia-se numa rede de parceiros? Quem são?
  • Recursos – Vai sempre necessitara de recursos. Dinheiro, pessoas, matérias primas, etc. Quais são? Quantos?
  • Estrutura de custos – Os recursos não são grátis por isso neles encontra a estrutura de custos do seu negócio. Onde vai gastar o seu dinheiro?

Os quatro pontos anteriores são ligados a mais quatro através da Oferta – O que vai oferecer ao seu mercado? O que propõe aos consumidores?

  • Relação com o cliente – Como estabelece contacto e se relaciona com os seus clientes?
  • Segmento de mercado – O seu negócio destina-se a um nicho de mercado? Qual?
  • Canais de distribuição – Como irá levar os  produtos/serviços até aos seus clientes?
  • Fluxos de entrada em caixa – Quanto dinheiro vai gerar com venda dos seus produtos/serviços?

Estes últimos quatro pontos estão relacionados com o mercado dos seus produtos/serviços.

Fica uma apresentação do “business modelo canvas:

Se não conseguiu encontrar a informação que procurava, pode encontrar os meus contactos no meu perfil do LinkedIn.
Continue Reading

Agile Product Management

Para o Outono de 2009, está previsto o lançamento do livro “Agile Product Management – Turning ideas into Winning Products with Scrum“. Na minha opinião, é um livro que faz falta.

Com cada vez mais organizações a adoptarem SCRUM para o desenvolvimento de software,  é importante que as responsabilidades do Product Owner sejam clarificadas e entendidas por todos.

De acordo com o autor Roman Pichler, este é um livro para todos os interessados em Agile Product Management, principalmente para os actuais Product Owners ou para quem está a pensar assumir essa função.

Já se podem ler o capítulo 1 e 2, e claro, dar o vosso feedback 🙂

Continue Reading

ISO 9001 e a Gestão de Projecto.

Já todos nós percebemos que a actual economia exige que os investimentos sejam feitos com mais cuidado, inteligência e rigor para que se obtenha o retorno esperado e sem surpresas.

As frentes são muitas, mas essencialmente, a maioria das empresas percebe que têm de ser mais “Lean“, eficientes, eficazes e oferecer produtos/serviços com mais qualidade.

Para combater na frente da qualidade as empresas apostam nos sistemas de gestão de qualidade. Pagam fortunas a empresas de consultoria e entidades certificadoras para terem os seus sistemas de gestão de qualidade certificados.

Para a certificação de sistemas de gestão de qualidade, o referencial normativo ISO 9001:2000 (ou a nova versão ISO 9001:2008) é o mais utilizado e reconhecido. O ISO 9001:2000 é parte de um conjunto de referenciais normativos que especifica o sistema de gestão de qualidade. O referencial normativo 9000:2005 define os fundamentos e vocabulário utilizado nos sistemas de qualidade enquanto o ISO 9004:2000 define um conjunto de linhas orientadoras para a melhoria contínua.

O normativo ISO 9001:2001 é uma abordagem à qualidade orientada a processos que se baseia em 8 princípios da gestão de qualidade. Todos os princípios devem ser seguidos, independente se existe ou não um sistema de gestão de qualidade certificado. Os oito princípios da gestão de qualidade, de acordo com o normativo ISO 9001:2000, são:

  • Focalização no cliente,
  • Liderança,
  • Envolvimento das pessoas,
  • Abordagem por processos,
  • Abordagem da gestão como um sistema,
  • Melhoria contínua,
  • Abordagem à tomada de decisão baseada em factos,
  • Relações mutuamente benéficas com fornecedores.

As especificações do sistema de gestão de qualidade do ISO 9001:2000 são implementadas de modo que os produtos ou serviços da empresa cumpram os requisitos de qualidade, i.e. que os produtos/serviços satisfazem as necessidades reais dos seu consumidores.

No entanto, especialmente em empresas de pequena dimensão, parece existir um grande mal entendido sobre a gestão de qualidade e gestão de projecto.

Não é raro ouvir-se falar em ISO 9001:2000 quando se pergunta sobre as metodologias de gestão de projecto que as empresas utilizam. É preocupante, no mínimo.

Enquanto um sistema de gestão de qualidade, como o ISO 9001, é de enorme valor, este, por si só, não é um sistema de gestão de projectos e não garante a qualidade dos resultados do projecto. O que garante a qualidade dos resultados dos projectos não são os processos, metodologias, normativos ou certificações. É a equipa do projecto. Os processos, metodologias e normativos ajudam as equipas de projecto a criar serviços/produtos que satisfazem as necessidades reais dos consumidores, e não ao contrário.

Por isso é importante que se reconheça o valor e os objectivos dos sistemas de gestão de qualidade. O controlo de configurações, gestão de incidentes, rastreabilidade, monitorização e medição, por exemplo, são características de um bom sistema de gestão de qualidade assim como de qualquer sistema de gestão de projectos, mas é necessário reconhecer que um SGQ ISO 9001:2000 é incompleto quando entramos na complexa área da gestão de projectos.

A gestão de qualidade é apenas uma pequena parte da gestão de projecto. E os objectivos de custo e de tempo?

Entre outros importantes aspectos, gerir um projecto é gerir a qualidade, o custo, o tempo, o âmbito, a satisfação do cliente e o risco para atingir os objectivos do projecto.

Existem normativos e metodologias que se encaixam perfeitamente e complementam os SGQ,  colocando as equipas de projecto numa posição privilegiada para conseguir criar produtos e serviços que satisfazem as necessidades não só dos seus clientes, mas também das empresas que aplicam esses normativos em gestão de projecto.

Um dos normativos que complementam os SGQ no âmbito dos projectos é o PMBoK® Guide (Project Management Body of Knowledge). O PMBoK® reúne o conhecimento sobre as melhores práticas na gestão de projecto. O PMBoK®, à semelhança do ISO 9001:2000 é orientado a processos e contém um total de 42 processos (PMBoK Fourth Edition), distribuídos por cinco grupos de processos e nove áreas de conhecimento.

Este grupos de processos e áreas de conhecimento podem aplicar-se a todos os projectos, independentemente da sua dimensão ou indústria. Os grupos de processos seguem a lógica de qualquer projecto: Iniciação, planeamento, execução, monitorização e controlo e fecho do projecto.

As áreas de conhecimento, definidass no PMBoK® como as necessárias para a gestão da maioria dos projectos, são:

  • Gestão de Âmbito do projecto,
  • Gestão de Tempo do projecto,
  • Gestão de Custo do projecto,
  • Gestão de Qualidade do projecto,
  • Gestão de Recursos humanos do projecto,
  • Gestão de Comunicação do projecto,
  • gestão de Risco do projecto,
  • Gestão de Compras do projecto,
  • Gestão de Integração do projecto (enquanto todas as outras oito áreas são lógicas e fáceis de perceber, esta por vezes não. Basicamente a gestão de integração do projecto consiste nos processos necessários para identificar, integrar e coordenar todos os restantes processos dos grupos de processos).

No entanto o PMBoK® não é uma metodologia de gestão de projecto. O PMBoK® define um corpo de conhecimento em gestão de projecto. As empresas têm de ser capazes de aplicar o conhecimento do PMBoK® e definir a própria metodologia de gestão de projecto, de acordo com a realidade da empresa e da indústria.

Enquanto o ISO 9001:2000 define os requisitos necessários de um Sistema de Gestão de Qualidade, a qualidade é apenas um dos aspectos da gestão de projecto. É importante ter o conhecimento sobre normativos e metodologias em gestão de projecto para que o resultado dos projectos estejam de acordo com as expectativas dos clientes e do negócio.

Para aumentar a probabilidade dos projectos gerarem o retorno desejado e sem surpresas, é necessário saber quais os objectivos de cada normativo e, sem esquecer, que os processos, metodologias e normativos ajudam as equipas de projecto a criar serviços/produtos que satisfazem as necessidades reais dos consumidores, e não ao contrário.

Nota. Obrigado miguelferrer por algumas correções.

Continue Reading