What if we stop treating software development as a project?
Dec 4th, 2015 by Joca

When we treat software development as a project, we are giving it a start and an end, since all projects have clearly defined starts and ends. If we think about starts, that’s ok. All software development efforts have a clearly defined start.


However, when we talk about end, software development and the software which is the product of the software development process may have an end but:

  • it’s quite difficult to define when is the end of the software development since that as soon as we put the very first version of the software in front of real users, we’ll receive a lot of feedback which we’ll make us start to think on opportunities to improve the software;
  • it’s quite difficult to define when is the end of the software. Every software exists to support one or more business processes, to reach certain business objectives while satisfying the needs of its users. As long as theses processes exist, and the software reaches the business objectives and satisfy the user needs, there’s no reason to end the life of the software.

For this reason both software development and the software which is the product of the software development process may have an end, but it is a clearly defined end. When we treat software development as project we are forced to define an end for this development since projects require a clearly defined end. In this situation we tend to define the software development end as the delivery of the software first release. But what happens after this delivery? Aren’t we going to do anything new in this software? Or should we start a new project to work on the next release of the software? If we decide to start a new project, what we will do while we don’t start to work on this new version?

This is why companies have started to treat software development as a continuous process, not a project, and the software as a product of this process. Software is a product with a clearly defined start, but no clearly defined end. The history of a software product is written during the life cycle of this product and the end depends a lot on the decisions made during this life cycle.

Hence the need of software product management in our industry.

Product Management book

Are you interested in the software product management topic? Do you to learn more about it? I wrote a book about the topic. The book has 5 main sections:

  • Definitions and requirements
  • Software product life cycle
  • Relationship with the other areas
  • Software portfolio management
  • Where should we use software product management

This book is recommended not only for those who have software as her core business. Companies who develop tailor made software as well as companies who use software to communicate with its customers like banks, schools, hospitals, etc., can also benefit from the book.

Interested? Well, the book is currently only available in Portuguese. So if you can read Portuguese, get your copy today!

If you don’t speak Portuguese, don’t worry! Paulo Caroli and I are working on translating the book into English, so feel free to leave a comment below, and we’ll let you know when the book is ready.

10 people like this post.

ThoughtWorks finally moves “product over project” from trial to adopt!
Nov 29th, 2015 by Joca

ThoughtWorks is a well known software development company which is always one step ahead of the rest of the software industry. Many people who contributed and continue to contribute to our industry are – or were – ThoughtWorkers. Martin Fowler, Jeff Patton, Neal Ford, Jim Highsmith, Rebecca Parsons, Ola Bini, Jim Webber, Luca Bastos, Paulo Caroli, Claudia Melo are just a small sample of people who work – or worked – there and have contributed a lot for the evolution of the software industry.

Since 2010 they publish a document called Technology Radar where they talk about their view on techniques, languages, platforms and tools for software development. This view is based on the experience from their consultants who work on a variety of software development endeavours from customers all over the world. They classify the techniques, languages, platforms and tools in four main categories:

  • Hold: when placed in this band, the item may be of interest to ThoughtWorks and others in the industry. However it is their opinion that the item is not ready to invest significant time and resources in which to build experience.
  • Assess: a technique, tool, language or platform that moves into the assess band of the radar is something that they believe is worth exploring with the goal of understanding how it will affect the technology impacted dimensions of your enterprise.
  • Trial: having established a radar item as something worth pursuing, it is important to understand how to build up this capability. Enterprises should look to trial the technology on projects that have a risk profile capable of taking onboard a new technology or approach.
  • Adopt: is the final stage that is of interest to them on the radar. Here they feel that the industry has begun to move beyond the trial phase and has found the proper patterns of usage for an item. An item may also appear in the adopt band if they feel strongly that the industry should be adopting a radar item now, rather than going through a more gradual adoption approach.

In May 2015 I was quite pleased when May’s Technology Radar edition brought “Products over Projects” as new technique and already recommended it as TRIAL. This showed that ThoughtWorks started to believe that software development should not be viewed as a project with a clear start and finish, but rather as a product, developed to support business processes of the owner of the software. This software will have a long life cycle, so long as the life cycle of the business processes it supports. For this reason, software development should not be viewed as a project with a predictable end, but rather as a product, a tool that will support the business processes for as long as the business processes exist.

I wrote about the differences between a product and a project back in 2011 and the more I work with software development, the more it get clearer to me that we should manage software development as a product, with a long lifecycle, with an unpredictable end. For this reason product management is so important for software development.

From trial to adopt

When I saw the November 2015 Technology Radar edition I was even more pleased when I saw that ThoughtWorks decided to move “products over projects” from trial to adopt. Doing so they now consider software product management as a technique that they feel strongly that the industry of software should be adopting in order to increase the chances of success of their software. Here it is in their own words:

We’ve long been championing the idea that thinking of software development as a project – something budgeted and delivered during a limited time slot – doesn’t fit the needs of the modern business. Important software efforts need to be an ongoing product that supports and rethinks the business process it is supporting. Such efforts are not complete until the business process, and its software, cease to be useful. Our observation of this products over projects approach, both with our own projects and outside, makes us determine that it is the approach to use for all but exceptional cases.

Certainly this will help people all over the world in creating better software, which will meet the needs of their customers while helping the software owners reach their objectives.

This is a great step forward for the software industry! This is great step forward for software product management! \o/

10 people like this post.

The IT problem
Mar 7th, 2014 by Joca

I have talked to some people lately about IT departments and how they seem disconnected from the companies they belong to, often being very reactive to business demands. It is common to hear complaints from the business people about IT saying they almost never deliver what was asked and that it is hard to understand what they say. On the other hand, it is also common to hear IT folks saying that the business area does not know what they want and that IT cannot answer “zillion” high priority demands of the business. This lack of understanding between IT and the business area of ​​the company is so common that it even became a subject of cartoons of all kinds:



But what is wrong? What is the IT problem?

Software development

For those who live in the part of IT that has to do with software development, this problem has been addressed for some time now. The Agile Manifesto, from 2001, makes this clear:

  • We have come to value customer collaboration over contract negotiation.
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Business people and developers must work together daily throughout the project.

As the software developers need to deploy their software somewhere, they decided to involve the people who takes care of the production environment in this new way of thinking that bring together IT and business. Thus was born the DevOps movement in 2009:

DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.

Source: Wikipedia

In these software development teams it is common to see someone with the role of Product Owner or Product Manager. This is a role I’ve already described earlier:

Product Manager is responsible for all aspects of a software product, from strategic objectives to the details of the user experience. She is responsible for making the connection between the business strategy and the problems and needs of customers through the software that should help the company achieve its strategic objectives while solving the problems and needs of the customers.

The IT problem

Now imagine the IT department of Gap, American Airline, Disney, MIT or any other non-tech company. These IT departments will have among its scope the following functions:

  • Hardware inventories.
  • Software inventory and installation.
  • Server availability monitoring and metrics.
  • Security management.
  • Anti-virus and anti-malware management.
  • Anti-manipulation management.
  • User’s activities monitoring.
  • Capacity monitoring.
  • Storage management.
  • Network capacity and utilization monitoring.

As you can see, these IT departments already have enough stuff to worry about and will hardly develop software. If they choose to develop software, they will most likely use third parties to do this development. Even if they decide to develop internally, software development is still a small piece of IT. The concern of these IT areas is with how to integrate off-the-shelf software and make them work to meet the business needs.

The problem is that unlike software development, which already discovered the importance of having a product manager to help deliver results more aligned with the business, all other functions of an IT department does not have this bridge between IT and the business.

One possible solution to the IT problem

I would like to propose a solution to the IT problem: have more people with the role of “product manager”. I believe that name does not fit very well when the IT delivery is not software. That person will need to create a bridge between IT and business. Perhaps a more appropriate name is “business manager”.

This person would have the following responsibilities:

  • Gather IT needs in all areas of the company and identify and propose solutions to any conflicts between these needs.
  • When these requirements have impact on the end customer of the company, understand this impact on these customers.
  • Negotiate requirement implementation priorities with all business areas.
  • Work with IT teams to ensure that deliveries are made in accordance with the requirements gathered with the other departments of the company.
  • Act with the demanding areas and IT teams on any relationship with suppliers / partners. (e.g. banks, consultants, etc.)
  • Inform all areas of the company on new IT implementations as well as upcoming implementations. Prepare training as needed.
  • Work with marketing to inform customers when the new implementations are customer facing.
  • Define, track and analyze usage metrics from IT, to use them as further relevant information for decision making.

And to be able to carry out these responsibilities, this person needs to have:

  • Experience working with IT teams to deliver quality projects within expected deadlines.
  • Good understanding of IT and technical topics to be able to negotiate delivery options. Having been in the IT field is not required, but may help in the function.
  • General knowledge about the company’s products and services, as well as an understanding of the different departments of the company.
  • Good oral and written communication skills.
  • Negotiation skills between different stakeholders with different priorities.
  • Ability to documente requirements and use cases.
  • Leadership.

As you can see from the above description, this person have a senior profile. It will be a pair of the IT manager.

A question that may arise while reading this proposal to add a “business manager” to the IT team is why IT managers can not assume this role? Actually, they can, but they shouldn’t. IT managers already have many concerns. The IT manager has two main focuses, technology and people. She needs to be up-to-date on the technologies in her area to learn how to better meet the needs that arise. And she needs to manage the team, finding and coordinating good IT professionals is no an easy task. Putting on the IT manager the additional burden of business requirement management can lower the overall quality in current tasks.

In software development we’ve realized that it’s better to have a separate person taking care of business needs. Why not apply the same role separation for other IT areas?

11 people like this post.

Why the hurry to launch an MVP?
Oct 7th, 2012 by Joca

I mentioned earlier that I was starting:

a new project called “The startup guide: how to create and manage profitable web products”. It’s a blog that will eventually become a book where I’ll explain how to create and manage a web product with a profit.

Well, I finished writing the book which is called “The Startup Guide: how startups and established companies can create and manage profitable web products“. The book is focused on how any type of company – no matter if it’s a startup or an established company – can create and profitably manage a web software. All it’s content is available at the “Guia da Startup” blog. It’s currently in Portuguese so it’s a good opportunity for you to practice reading in a new language. If you are not up-to-date with your Portuguese skills, there’s the option of using Google Translate but some meaning may be lost in translation. For these reason I intend to translate the content into English eventually.

One of the most popular posts from this blog is about the reasons to make fast the first version of your product. Why do we need to make an MVP? Why not wait to have the product with more features to launch it? Herb Kelleher, co-founder and former CEO of Southwest Airlines has a famous phrase to motivate people to do things:

“We have a ‘strategic plan.’ It’s called doing things.”

This “strategic plan” can be translated into the #jfdi hashtag which means something in the lines of “just focus and do it” or “just freakin’ do it” (polite form).

But why the hurry? Why can’t we keep working on our product until we feel comfortable it has all the features we believe are needed to solve the user’s problem?

Well, there are 3 main reasons:

Reason #1: The moment of truth!

The longer you take to put your product in front of real users, the longer you take to start getting feedback from real people to know if you’re on the right track. And what’s even worse, you’ll probably be giving too many steps in the wrong direction.

A software is supposed to solve a certain problem of its users. You will not know if you have built a good product until the product is used by real users and it actually solves one of their problems. The longer it takes for this to happen, the longer it will take for you to know if your product is or is not the solution for someone’s problem.

And if it is not, what should you do? Change, adapt and present it again to real users! The sooner you know that what you’re developing is not on track, the better, because you’ll have spent less time, energy and money moving into the wrong direction.

Reason #2: Featuritis

There’s a limit to the number of features an user can understand. When we present a software full of features to a potential user, instead of providing her with a possible solution to one of her problems, we may end up creating a new problem for her. Kathy Sierra, a well known software development and user experience instructor, designed the Featuritis Curve that illustrates in a clear and fun way how user satisfaction diminishes as we increase the number of features of a product.

Reason #3: ROI

The longer you take to put your product in front of real users, the longer it will take for you get some revenue and the longer you’ll have to invest from your own money or investor’s money. Below is a typical return on investment chart. While you don’t launch your product and don’t have revenue, all you’ll have are costs, i.e., you’ll be in the investment phase of the curve below. This situation will only change when you get some revenue and this revenue pays your monthly costs. This is the monthly profitability phase in the chart. Only after a few months in the monthly profitability phase you’ll be able to get to the return on investment phase. It’s a long way:

Now take a look at the chart below. If you decide to delay your launch in 3 months, this can delay your return on investment in 6 months! Are the features that you intend to implement in those 3 months you are delaying the product launch worth the 6 months delay to get to the return on investment phase?

On the other hand, if you are able to launch 3 months sooner than what’s described in the first chart, you’ll get into the return on investment phase 6 months sooner. Isn’t that worth figuring out how to launch your product faster?

If you’re not embarrassed…

There is a famous quote by Reid Hoffman, founder of LinkedIn, which really resonates with the MVP concept:

“If you are not embarrassed by the first version of your product, you’ve launched too late.”

To illustrate this quote, here are some print screens of early versions of well known software products:

Google in 1998

Twitter in 2006

Linkedin in 2005

Facebook login screen in 2005

Facebook in 2005

Next post

Last year I decided to run a lean startup experiment. Would it be possible to build a software and market it without using Locaweb’s marketing power? The result of this experiment is a calorie counter web product with more than 17,000 registered users in less than one year of operation. In my next post I’ll explain how I built the first version of this product in 10 days.

14 people like this post.

How to create a good checklist
Mar 16th, 2012 by Joca

I already mentioned about “The Checklist Manifesto” book in two previous posts, one explaining how important it is to use checklists, and another one on using checklists to deal with the unexpected.

In this post I’ll reproduce some of my highlights from the book. These highlights provide advice on how to create a good checklist:

Pilots nonetheless turn to their checklists for two reasons. First, they are trained to do so. They learn from the beginning of flight school that their memory and judgment are unreliable and that lives depend on their recognizing that fact. Second, the checklists have proved their worth—they work.

There are good checklists and bad, Boorman explained. Bad checklists are vague and imprecise. They are too long; they are hard to use; they are impractical. They are made by desk jockeys with no awareness of the situations in which they are to be deployed. They treat the people using the tools as dumb and try to spell out every single step. They turn people’s brains off rather than turn them on. Good checklists, on the other hand, are precise. They are efficient, to the point, and easy to use even in the most difficult situations. They do not try to spell out everything—a checklist cannot fly a plane. Instead, they provide reminders of only the most critical and important steps—the ones that even the highly skilled professionals using them could miss. Good checklists are, above all, practical.

No matter how much thought we might put in, a checklist has to be tested in the real world, which is inevitably more complicated than expected. First drafts always fall apart, he said, and one needs to study how, make changes, and keep testing until the checklist works consistently.

The checklist cannot be lengthy. A rule of thumb some use is to keep it to between five and nine items, which is the limit of working memory.

You must decide whether you want a DO-CONFIRM checklist or a READ-DO checklist. With a DO-CONFIRM checklist, he said, team members perform their jobs from memory and experience, often separately. But then they stop. They pause to run the checklist and confirm that everything that was supposed to be done was done. With a READ-DO checklist, on the other hand, people carry out the tasks as they check them off—it’s more like a recipe.

5 people like this post.

Collaboration lessons from the marshmallow challenge
Jun 14th, 2011 by Joca


  • Groups of 4 people
  • 20 sticks of spaghetti
  • one yard of tape
  • one yard of string
  • a marshmallow

Time constrain: 18 minutes

Objective: tallest freestanding structure


  • Who consistently performs worst? Recent business school graduates
  • Who consistently performs well? Recent kindergarten school graduates. Not only the tallest but the most interesting structures.
  • Why kindergarten school graduates do better than business school graduates? First, none of the kids spent any time trying to be CEO of “Spaghetti Inc.”. Business students are trained to find the single right solution. Kindergarteners build prototypes several times, get instant feedback of what work and what doesn’t and refine.
  • The very best group? Architects and engineers, thankfully!
  • CEOs with an executive admin perform significantly better than just CEOs. Why? Because they have special skills of facilitation. They manage the process.
  • Specialized Skills + Facilitation Skills = Success!
  • Incentives + Low Skills = no success.
  • Incentives + High Skill = Success!
  • Every project has its own marshmallow.
  • Shared Experience + Common Language + Prototyping & Facilitation
  • Sometimes a little prototype is all it takes to transform an Oh-Oh moment into a Ta-Da moment!
  • 1 person likes this post.

    Qual a diferença entre gerir um projeto e gerir um produto?
    Aug 2nd, 2010 by Joca

    Nos meus posts recentes sobre acompanhamento de projetos ágeis e o uso de burnups acabei me deparando com algumas questões mais “filosóficas” sobre produtos, projetos, gestão de produtos e de projetos e os papéis de PO (product owner) e scrum master nas metodologias ágeis.

    Projetos e produtos

    Projetos e produtos


    Primeiro algumas definições básicas:

    A project in business and science is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim.

    Fonte: http://en.wikipedia.org/wiki/Project

    The noun product is defined as a “thing produced by labor or effort” or the “result of an act or a process”, and stems from the verb produce, from the Latin prōdūce(re) ‘(to) lead or bring forth’.

    Fonte: http://en.wikipedia.org/wiki/Product_(business)

    Ou seja, enquanto o projeto é um processo com começo, meio e fim, o produto é o resultado de um processo, de um esforço.

    Então gerir projetos e gerir produtos são duas funções distintas?

    Parece que sim. Enquanto se está gerindo um projeto, a preocupação é com o processo e com tudo o que o cerca, ou seja, se está no prazo, se tem os recursos necessários e se está sendo feito conforme esperado (qualidade e escopo).

    Por outro lado, quando se gere um produto, a maior preocupação é, ou pelo menos deveria ser, garantir que produto resolve um problema do cliente a quem esse produto é destinado.

    Em um post de 2007 do blog How To Be A Good Product Manager, o autor Jeff Lash lembra alguns pontos importantes que não devemos esquecer quando pensamos em gestão de projetos e gestão de produtos:

    • Just like every product needs a product manager, every project needs a project manager.
    • Just because product managers think they can manage their own projects does not mean they should.
    • The skills, talents, and traits involved in project management are very different from those involved in product management.
    • Just like it is hard to find one single person who can fill the product management role and the product marketing role, it is hard to find one person who can be successful at both the product management and the project management role.
    • Project management is not a stepping stone to product management, nor vice versa.
    • Good project managers are just as valuable as good product managers.
    • Finding a good project manager to manage your projects will help you be an even better product manager.
    • The less time product managers spend on project management, the more time they will be able to spend on product management.
    • To avoid conflicts between product management and project management, product managers, project managers, and project teams should all agree on shared goals and objectives as much as possible.

    Marty Cagan deixa claro a necessidade de separação desses papéis em um de seus posts:

    For Internet services companies, it really is important that the roles be separate. You’ll thrash in release management if you don’t, and releases will consistently be delayed and take longer than they should.

    E como as metodologias ágeis vêem essas funções?

    As metodologias ágeis, mais especifcamente o Scrum, tem dois papéis claros no time, um focado mais no projeto, o Scrum Master e outro focado mais no produto, o Product Owner (PO):

    [Scrum] Roles:

    Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.
    ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.
    Team: A cross-functional group of people responsible for managing itself to develop the product.
    Scrum Team: Product Owner, ScrumMaster and Team

    Fonte: http://en.wikipedia.org/wiki/Scrum_(development)

    Há um artigo na InfoQ com o título “Can Product Owner and Scrum Master be Combined?” em que o tema de ter um única pessoa gerindo projeto e produto é discutido. Tanto nas opiniões que compõem o texto e que incluem testemunhos de pessoas como Mike Cohn e Ken Schwaber, quanto nos comentários do texto é unânime que apesar de ser possível combinar as duas funções e, se o time for muito pequeno, ser até aceitável, o mais recomendado é que essas funções sejam desempenhadas por pessoas diferentes.


    • Gerir um projeto é garantir que o processo está fluindo da melhor forma possível, dentro do prazo, com os recursos disponíveis e atingindo os objetivos de escopo e qualidade definidos. Ou seja, gerir projetos é olhar para dentro da organização.
    • Gerir um produto é garantir que o resultado de um processo satisfaça as necessidades do cliente. Ou seja, gerir produtos é olhar para fora da organização.
    • É possível e, se o time for muito pequeno (até 5 pessoas), pode ser até aceitável combinar as duas funções. Contudo, o mais recomendado é que essas funções sejam desempenhadas por pessoas diferentes.
    2 people like this post.

    Protótipos de baixa fidelidade, croquis, simplicidade, Gantt e burnup
    Jul 26th, 2010 by Joca

    Essa semana tive a oportunidade de conversar com Gil Barros, um profissional muito experiente de design de interação e de arquitetura da informação, que está fazendo doutorado na FAU-USP sobre prototipação e o uso de croquis.

    …croquis (palavra francesa eventualmente aportuguesada como croqui ou traduzida como esboço ou rascunho) costuma se caracterizar como um desenho rápido, feito com o objetivo de discutir ou expressar graficamente uma idéia…

    O que costuma ser mais importante no croquis é o registro gráfico de uma idéia instantânea, através de uma técnica de desenho rápida e descompromissada.

    fonte: http://pt.wikipedia.org/wiki/Croquis

    Ele comentou que vê pouca gente se valendo do desenho feito à mão para mostrar ideias e que, por achar essa opção como uma das formas mais ágeis de comunicacão, resolveu dedicar seu doutorado a esse tema.

    Eu já havia comentado sobre a importância dos rascunhos, ou protótipos feitos à mão, no post “Protótipo: primeira impressão” e no post “Mais um exemplo de protótipo de baixa fidelidade“.

    O que me atrai nos protótipos de baixa fidelidade e em croquis de forma geral é sua simplicidade inerente. Quem me conhece sabe que sou fã da simplicidade, tanto que já escrevi sobre o tema no post “Simplicidade” e em um outro post onde comento sobre um site de 1 única página.

    Semana passada, quando escrevi sobre as vantagens do uso dos gráficos de burnup como opção aos Gantt Charts para acompanhamento do andamento de projetos, acabei não comentando de uma das vantagens mais óbvias do burnup: o burnup é mais simples que o Gantt Chart pelo simples fato de que burnups podem ser feitos à mão. Já o Gantt Chart é muito difícil de ser feito à mão.

    A prova disso é a busca de imagens do Google. Experimente pesquisar por Gantt Chart e por burnup chart.

    Logo na primeira página da pesquisa por imagens de burnup chart são 4 gráficos feitos à mão. Já na pesquisa por Gantt Chart, não encontrei nenhum…


    Burnup feito à mão

    Outro exemplo de burnup

    Outro exemplo de burnup feito à mão

    Burn down que aparece na busca por imagens de burnup

    Burn down feito à mão que aparece na busca por imagens de burnup

    Mais um exemplo de burnup

    Mais um exemplo de burnup feito à mão

    Be the first to like.

    Acompanhamento de projetos ágeis
    Jul 19th, 2010 by Joca

    Na gestão de projetos tradicional existe o famoso Gantt Chart que permite saber com precisão quanto tempo um projeto vai levar, quanto tempo demorará cada tarefa do projeto, que tarefa depende de qual tarefa e se alguma atrasar, o que acontece com o projeto.

    Gantt chart

    Gantt chart

    O Gantt Chart não se aplica a contento para projetos de software que usam metodologias ágeis pois ele pressupõe o conhecimento completo de todas as tarefas e fases do projeto antes de seu início, enquanto que nas metodologias ágeis “responder às mudanças tem mais valor que seguir um plano”, ou seja, as metodologias ágeis entendem que mudanças sempre vão acontecer e que o melhor a fazer é estar preparado para as aceitá-las.

    O cone da incerteza

    Já que mudanças sempre vão acontecer, como podemos acompanhar um projeto ágil, saber qual é o prazo de entrega desse projeto e, ao longo do projeto, saber se ele está dentro do prazo? Mesmo antes das metodologias ágeis já existia o conceito do cone da incerteza que diz que a precisão das estimativas de prazo de um projeto é muito pequena no início do projeto e aumenta ao longo do tempo. Aliás, não só a precisão das estimativas de prazo, como também de custos e de escopo que, juntos com o prazo, são os três limitadores de todo projeto.

    Cone da incerteza

    Cone da incerteza

    O cone da incerteza se aplica a qualquer projeto, quer ele use metologias ágeis ou metodologias de gestão de projetos mais tradicionais. Ou seja, mesmo tendo um Gantt Chart, no início do projeto não teremos precisão sobre seu prazo. O Gantt Chart passa uma falsa impressão de que está tudo sob controle, mesmo com todas as incertezas que existem no início de qualquer projeto.

    Mas eu tenho que ter um prazo…

    Contudo, mesmo levando em conta o cone da incerteza, é possível ter uma estimativa de prazos, nem que seja algo como “esse projeto vai ficar pronto em setembro” o que significa que ele pode ficar pronto em qualquer um dos 30 dias de setembro, ou “esse projeto será entregue no terceiro trimestre de 2011” o que dá 45 dias para mais ou para menos de margem de erro! 🙂

    Prazos têm que existir e te que ser respeitados.

    E não raro há casos em que prazo é fixado por quem pediu o projeto (“o site dessa promoção tem que ser publicada até 15 de julho pois nesse dia teremos uma campanha direcionando para esse site”). Nesses casos nos sobram escopo e recursos para mexer sendo que às vezes adicionar mais recursos não faz o projeto andar mais rápido.

    De qualquer forma, tanto tendo um prazo fixo (“15 de julho”) quanto podendo dar estimativas um pouco mais abertas (“em setembro”, “terceiro trimestre de 2011”), é preciso saber se estamos dentro do prazo para podermos tomar decisões (trazer mais gente? reduzir escopo? negociar mais prazo?).

    Como fazer acompanhamento de projetos ágeis?

    Projetos ágeis podem fazer uso de gráficos burnup para podermos ter melhor visibilidade de seu andamento. Não estou falando dos gráficos burnup de cada iteração, que interessam apenas à equipe que está tocando o projeto, mas sim um burnup do projeto inteiro que trará informações úteis para todas as pessoas interessadas nesse projeto.

    Veja o exemplo do gráfico abaixo:



    Nesse exemplo temos uma definição inicial do esforço necessário para terminar um determinado projeto que teria começado em 7/1/2008. O esforço necessário para concluir esse projeto é de quase 100 “xpto”, que está marcado na linha verde. Esse “xpto” pode ser pontos ou horas ou features ou o que quer que usemos para medir progresso de desenvolvimento.

    Note no exemplo que nos dias 4/2, 18/2 e 31/3 houve aumentos do esforço necessário. Se não fossem esses aumentos o projeto estaria concluído até 24/3. Com os aumentos passou para 21/4, quase um mês de atraso.

    A linha vermelha mostra a velocidade do time. A inclinação dessa linha é o indicativo da velocidade: quanto menor a inclinação, mais devagar o time e, consequentemente, o projeto está andando.

    Por que um gráfico burnup como esse é importante?

    Ele vai ajudar o time e todos os interessados no projeto a entender seu andamento. Esse gráfico deve andar junto com uma espécie de log para entendermos porque aumentou o esforço necessário, ou porque o projeto está andando mais devagar.

    Não é necessário nenhum software especial para fazer esses gráficos. Uma planilha pode dar conta do recado, ou mesmo o bom e velho papel e lápis!

    Normalmente o esforço necessário para entregar um projeto pode aumentar porque aumentou o número de funcionalidades a ser entregue (aumento de escopo) ou apareceram dificuldades técnicas não previstas. Esse esforço pode diminuir quando há diminuição do escopo do projeto.

    Razões comuns para diminuição de velocidade do projeto são o surgimento de dificuldades técnicas não previstas ou a entrada de um projeto extra que está divergindo esforços da equipe ou ainda a saída de um ou mais membros da equipe antes do término do projeto.

    Enfim, a idéia é conseguir ter maior visibilidade e, consequentemente, mais informações para que se possa intervir quando necessário para garantir a entrega dos projetos dentro do prazo estimado.

    3 people like this post.

    »  Substance: WordPress   »  Style: Ahren Ahimsa