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.