Priorizando projetos de TI

Estava lendo um artigo na cio sobre priorização de projetos de TI.

Esta priorização muitas vezes funciona como um malabarismo, pelas diferentes áreas de negócio demandando projetos. Lá pelas tantas, se fala:

“Os modelos formais e mecanismos de priorização não funcionam mais”, diz David Cearley, vice-presidente do Gartner. “A priorização não pode ser feita de forma isolada do negócio. Precisa acontecer em estreita parceria com a empresa.”

Nesse cenário, a TI está sentindo a pressão para ser mais ágil em seus métodos de entrega, mais flexível na priorização de projetos, e mais experiente na avaliação de ROI – tudo para que possa trabalhar com, e não contra, as necessidades de negócio.

Um dos pontos é em evitar constantes “não” para os clientes. Mas o ponto não é este. O não é muito bom para testar reais necessidades. Quando um cliente requisita uma nova funcionalidade ou um novo projeto, perguntar “O que acontece se este projeto não for entregue? O que se perde?“, pode ser uma forma de buscar o real valor do projeto. Claro, você deve saber se tem um ambiente propício para isto. Senão a resposta pode ser… “Ah, o que se perde? Seu emprego.

Quando escrevemos uma user story, queremos saber questões como o porque ela precisa ser implementada, o que de deve ser implementado, e quem se beneficia com isto. Para um pensamento mais “amplo”, em projetos, esta linha de pensamento serve igual. Isto me lembra a Project Story do Luiz Parzianello, que eu curto muito. Ela é um documento que consegue criar uma visão mais clara de um projeto a ser entregue. E é uma forma para empresas se organizarem e criarem governança na hora de escolher o que priorizar e porque priorizar. Temos outras formas de fazer isto, seja pensando em uma estrutura de Business Canvas e Lean Startup.

E neste sentido, é interessante como as grandes empresas dificilmente conseguem ver valor em estar mais próximas das áreas de negócio. E em trabalhar com ciclos mais curtos de entrega. Deixando as áreas de negócio realizarem testes, desenvolvendo produtos mais rapidamente e testando o seu resultado é pelo menos um exercício para minimizar risco. É muito importante para a equipe de desenvolvimento estar próxima dos clientes, pois assim poderão ajudar na priorização de funcionalidades em um lado mais técnico e entender mais dos processos de negócios envolvidos.

Depois no artigo, este assunto vem a tona:

O alto nível de envolvimento das partes interessadas também levou TI a repensar seu processo de desenvolvimento, passando a adotar uma abordagem mais ad hoc quando as equipes de TI passam a integrar o pessoal de marketing ou das áreas de negócios para o desenvolvimento mais rápido de um aplicativo móvel  – às vezes em questão de dias em vez de semanas ou mesmo meses.

O foco aqui não é entrega rápida de aplicativos de mobilidade. Quero focar em entrega de projetos em geral. E quando se fala em abordagem ad hoc… o que o pessoal deveria olhar são as metodologias ágeis puramente, porque muitas das preocupações citadas, são na verdade princípios e questões que as equipes ágeis valorizam.

Para que isto ocorra de forma efetiva, a formação de equipes menores para se trabalhar em projetos, dentro das áreas de negócio é uma boa solução, só que o problema é que normalmente as equipes “tradicionais” não são preparadas e estimuladas a assumirem mais de um papel. Isto deve ser trabalhado e permitido. E com o cliente presente para ajudar nas definições, os ganhos serão vistos de forma rápida.

O tempo de resposta das equipes é cada vez menor. E para que isto possa ocorrer desta forma, devemos estar leves e comprometidos com o essencial, permitindo sempre uma revisão de rumo e constante avaliação se algo pode ser melhorado no processo diário.

Vinicius Teles uma vez me disse que “o cliente só sabe o que quer depois que vê o que pediu“. Neste sentido o que queremos fazer é lançar logo software para que os clientes possam avaliar e prover feedbacks. Só que muitas empresas ainda não caíram na real e algumas só vão se ligar em certas práticas quando a água estiver chegando no nariz.

pt: Agile Brazil 2011 – Aí vou eu!

Eu vou no Agile Brazil 2011, e vou participar de algumas atividades durante o evento. Vamos por dia!

Dia: 27 de junho de 2011
Treinamento de Test Driven Development com outras figuras da comunidade ágil do Brasil. Na edição de 2010 oferecemos um treinamento de eXtreme Programming. Neste ano vamos focar na prática de Test Driven Development, trabalhando com práticas relacionadas ao TDD. TDD é para a vida inteira!

Dia: 28 de junho de 2011
Estarei assistindo o treinamento de Lean, do meu amigo Christopher G. Thompson, do Lean Institute Brasil. Estarei lá para participar de boas discussões!

Dia: 29 de junho
Inicio no primeiro dia de evento com o workshop Da visão a produção – Criando produtos e lançando ao mercado. A ideia é dar dicas de como estruturar a criação de um produto e preparar o seu lançamento. A partir de ideias elaboradas de exemplos de produtos os participantes serão desafiados a trabalhar questões como roadmap, pitch de venda, lançamento estilo hollywood, e formas de como criar um produto que pode ser lançado aos poucos e realmente testar e buscar mercado. É colocar as práticas ágeis e conceitos de lean startups na prática e poder levar isto para a vida real. Serão 110 minutos de prática! Aparece lá!

Dia: 30 de junho
Lightning Talk “Jogue basquete e desenvolva times multifuncionais“. O objetivo é falar a respeito dos ensinamentos do basquete e como as equipes podem crescer com isto.

Lightning Talk “Ramones ou Jazz? Ou os dois? Buscando produtividade com músicas” em par com o Helio Medeiros (@helmedeiros). Objetivo da palestra? Gerar concentração, buscar motivação, acreditar que uma música pode ajudar a buscar resultados. Tudo isto usando a pomodoro technique em um ritmo alterado, através das músicas e do “songdoro”, que mistura pomodoro technique com o conceito das powersongs.

Lightning Talk “Desenvolvimento Orientado a Testes — Está na hora de aplicar no seu trabalho!“. Em uma entrevista de emprego, o candidato se diz praticante de Test Driven Development. Pratica em casa nos projetos pessoais, na faculdade, nos coding dojos que participa nas comunidades que faz parte, mas não pratica no trabalho. Lá não dá. E como fica? Descubra abordagens para fazer o assunto acontecer no trabalho também.

Fora isto, espero poder participar e puxar alguns Coding Dojos e parear com algumas pessoas! Os projetos podem ser o @catarse_, o @letshelpit ou algum outro projeto que apareça até lá… e pior que vai aparecer mesmo. Faço atualizações por aqui… 🙂

Acompanhe as últimas novidades do evento pelo twitter @agilebrazil ou siga a tag #AgileBR para obter mais informações e comentar sobre o evento.

A Trevisan Tecnologia, empresa que atuo como CTO, é uma das apoiadoras do evento. Poder contribuir com a evolução e o ensino do assunto no mercado brasileiro deve ser tarefa de todos. Seja ensinando práticas enquanto ensina uma nova linguagem de programação, seja criando uma nova empresa com os princípios do Lean Startup e por aí vai.

Se a sua empresa também tem interesse em apoiar com patrocínio, veja mais informações no próprio site do Agile Brazil.