Atualmente trabalho com o desenvolvimento de software, e dentro do rol de responsabilidades estão aquelas gerenciais, como gestão de custo, prazos, equipes, aquisições e etc. Existe um bom nível de aceitação das práticas ágeis, mas existe em minha opinião uma dificuldade enorme em aplicar estas práticas, por mais que estejam como "aceitas". A dificuldade surge quando entramos nas atividades hoje coordenadas por gerentes de projeto, pois preciso do cronograma do projeto, do orçamento do projeto e assim por diante.
A um tempo, venho provocando o pessoal de que a adoção das práticas necessitam de uma mudança na forma como olhamos para o software. Eu penso que não podemos olhá-lo apenas como um projeto, pois não está claro quando o mesmo termina, e a premissa básica na palavra projeto é que ele tem um fim conhecido. Nesta linha, penso no software como um produto, que provavelmente terá um fim (fim no sentido de término e não de objetivo), mas que este não é conhecido, e logo o ferramental que eu tenho para gestão de projetos não se aplica na gestão de produtos. Quando penso em produto tenho que pensar na satisfação do usuário (e não em atender os requisitos do projeto), em time to market, em gestão do ciclo de vida e operação, acordos de nível de serviços e etc.
Com o conhecimento que tenho, creio que Lean, Scrum, XP, Kanban e etc. não cobrem todos os aspectos, mas podemos combinar o ferramental oferecido por estas práticas na composição da gestão do produto. O Mínimo Produto Viável por exemplo serve como base para o desenvolvimento do produto e busca garantir que o mesmo já esteja disponível no mercado o quanto antes, permitindo o retorno rápido dos clientes. A figura dos Backlogs e desenvolvimento iterativo e incremental são úteis para eliminação antecipada de riscos, visibilidade imediata das melhorias e diminuem o desperdício (especialmente com planejamento antecipado).
Em resumo, creio que em trabalhos como o meu, onde apoiamos áreas de negócio por meio do desenvolvimento de sistemas computacionais, devemos mudar nossa cultura de projetos para uma cultura de produtos, onde utilizamos um capital base (investimento, capital de risco) para alavancar uma ideia, lançamos rapidamente no mercado (interno no nosso caso), mensuramos a aceitação e o retorno do investimento, assim como coletamos expectativas e identificamos stakeholders. Com esta informação tomamos decisão sobre a continuidade do investimento, ou em alguns casos, o próprio já é capaz de se sustentar com base na tarifação de seu uso. Temos também expectativas que direcionarão o produto e serão processadas em um backlog, liberando funcionalidades continuamente em períodos pré-estabelecidos. Caso o investimento não apresente o retorno desejado, falhamos rapidamente e podemos abandonar a iniciativa com perdas menores, ou buscar uma correção de rumo antecipada.
Para tratarmos a questão em escala, recomendo fortemente a leitura do livro Agile Software Requirements do Dean Leffingwell, onde é apresentado o Scaled Agile Framework, um compilado das práticas ágeis que visa apoiar organizações com sistemas de larga escala assim como aquelas com um amplo portfólio.
Recentemente também achei este artigo do Cutter Blog (com autores de peso) que diz, talvez com mais propriedade, o que procurei explanar neste post. E felizmente, me fez pensar que não estou só neste mundo de Gerentes de Projeto que gostariam mesmo de ser Gerentes (ou Donos) de Produtos.
A um tempo, venho provocando o pessoal de que a adoção das práticas necessitam de uma mudança na forma como olhamos para o software. Eu penso que não podemos olhá-lo apenas como um projeto, pois não está claro quando o mesmo termina, e a premissa básica na palavra projeto é que ele tem um fim conhecido. Nesta linha, penso no software como um produto, que provavelmente terá um fim (fim no sentido de término e não de objetivo), mas que este não é conhecido, e logo o ferramental que eu tenho para gestão de projetos não se aplica na gestão de produtos. Quando penso em produto tenho que pensar na satisfação do usuário (e não em atender os requisitos do projeto), em time to market, em gestão do ciclo de vida e operação, acordos de nível de serviços e etc.
Com o conhecimento que tenho, creio que Lean, Scrum, XP, Kanban e etc. não cobrem todos os aspectos, mas podemos combinar o ferramental oferecido por estas práticas na composição da gestão do produto. O Mínimo Produto Viável por exemplo serve como base para o desenvolvimento do produto e busca garantir que o mesmo já esteja disponível no mercado o quanto antes, permitindo o retorno rápido dos clientes. A figura dos Backlogs e desenvolvimento iterativo e incremental são úteis para eliminação antecipada de riscos, visibilidade imediata das melhorias e diminuem o desperdício (especialmente com planejamento antecipado).
Em resumo, creio que em trabalhos como o meu, onde apoiamos áreas de negócio por meio do desenvolvimento de sistemas computacionais, devemos mudar nossa cultura de projetos para uma cultura de produtos, onde utilizamos um capital base (investimento, capital de risco) para alavancar uma ideia, lançamos rapidamente no mercado (interno no nosso caso), mensuramos a aceitação e o retorno do investimento, assim como coletamos expectativas e identificamos stakeholders. Com esta informação tomamos decisão sobre a continuidade do investimento, ou em alguns casos, o próprio já é capaz de se sustentar com base na tarifação de seu uso. Temos também expectativas que direcionarão o produto e serão processadas em um backlog, liberando funcionalidades continuamente em períodos pré-estabelecidos. Caso o investimento não apresente o retorno desejado, falhamos rapidamente e podemos abandonar a iniciativa com perdas menores, ou buscar uma correção de rumo antecipada.
Para tratarmos a questão em escala, recomendo fortemente a leitura do livro Agile Software Requirements do Dean Leffingwell, onde é apresentado o Scaled Agile Framework, um compilado das práticas ágeis que visa apoiar organizações com sistemas de larga escala assim como aquelas com um amplo portfólio.
Recentemente também achei este artigo do Cutter Blog (com autores de peso) que diz, talvez com mais propriedade, o que procurei explanar neste post. E felizmente, me fez pensar que não estou só neste mundo de Gerentes de Projeto que gostariam mesmo de ser Gerentes (ou Donos) de Produtos.
Comentários